mksquashfs unsquashfs squashfuse

See notes around a third of the way down this GitHub page

squashfuse has been ported into FreeBSD ... see Thread 56767

So if you use packages you can install

pkg install squashfs-tools
pkg install fusefs-squashfuse

squashfs-tools provides mksquashfs and unsquashfs commands that create (extract) compressed file system images. Say for instance you want to make a backup of your current running system then you might

cd /tmp
mksquashfs / backup.sfs -e tmp

which basically is saying make a copy of everything from / down storing that into a squashed filesystem file called backup.sfs. The -e parameter indicates to exclude the /tmp folder from being backed up ... as in this case that is where the backup.sfs file (squashed filesystem) is being created and not excluding that folder would enter into some kind of eternal loop of copying itself (backup.sfs file).

That backup.sfs squashed filesystem single file can be extracted using something like

cd /tmp
unsquashfs -f -d / backup.sfs

that tells unsquashfs to force extract to the / folder the content of backup.sfs

I've only used the above purely as a example. Copying and restoring a live running system wouldn't be a wise choice as you'd start over-writing some system files with versions that were recorded in the backup ... that likely would crash the system. More usually you'd use mksquashfs and unsquashfs in a similar manner to using tar or zip on selected folders only, or perhaps to backup a whole system but having booted from the freebsd boot CD.

squashfuse provides a means to mount a single squashed filesystem file and browse around those files (read only). squashfuse requires the fuse module to be loaded i.e. edit /boot/loader.conf to include
and then after rebooting that will be active. You can then mount a file such as backup.sfs running (as root)

mkdir m
to create a mount point directory

squashfuse backup.sfs m

after which you can cd to m and start browsing the contents. Afterwards umount that by changing directory to where the m folder is and

umount m

As the above linked GitHub entry suggests
If you don't yet use SquashFS, consider starting, now that squashfuse exists. For many uses, the chief drawbacks of SquashFS were requiring Linux and root access, but squashfuse has that covered.

- Use SquashFS for archival and backup, instead of tar.
It offers faster creation (multi-core), and browsing without unpacking.

- Use SquashFS instead of zip.
It has better compression, and faster directory lookup.

- Use SquashFS instead of compressed disk images like DMG, uzip or Partimage.
It has better compression and portability.

If you have htop installed, fire that up whilst making a squashfs and you'll see that it uses all of the cores available i.e. multi cores will create a sfs quicker than a single core as it does things in parallel.

mksquashfs shows a nice progress bar as its running that provides a indication of how long its going to take to complete

For unchanging folders there are potential distinct advantages from using squashfs. For example my freebsd desktop's du -s /usr/lib folder indicates 514MB of contents. mksquashfs /usr/lib usr-lib.sfs -comp lz4 compresses that to 198MB, adding the -Xhc (higher compression) switches reduces that further to 160MB. lz4 high compression takes longer to compress, but doesn't affect decompression speeds (so is quicker when reduced to smaller file size).

In using multiple cores lz4 decompression speeds when reading a .sfs file off a SSD can approach ram speeds. Basically squashfs is similar to zip type compression, but rather than compressing each file it compresses file blocks.

I note however that there has been little progress with squashfs within FreeBSD, little/no interest. The likes of unionfs ... continues to not cater for .wh whiteout files, where otherwise the read only squashfs file can be layered so as to be rw like, and also squashfuse only supports xz or zlib compression formats.

Shame :( as speed improvements can be considerable. But then again in a world of 32GB common desktops, cached IO is near 100% of the base system anyway.