| SQUASHFS 4.3 - A squashed read-only filesystem for Linux | 
 |  | 
 | Copyright 2002-2014 Phillip Lougher <phillip@lougher.demon.co.uk> | 
 |  | 
 | Released under the GPL licence (version 2 or later). | 
 |  | 
 | Welcome to Squashfs version 4.3. Please read the README-4.3 and CHANGES files | 
 | for details of changes. | 
 |  | 
 | Squashfs is a highly compressed read-only filesystem for Linux. | 
 | It uses either gzip/xz/lzo/lz4 compression to compress both files, inodes | 
 | and directories. Inodes in the system are very small and all blocks are | 
 | packed to minimise data overhead. Block sizes greater than 4K are supported | 
 | up to a maximum of 1Mbytes (default block size 128K). | 
 |  | 
 | Squashfs is intended for general read-only filesystem use, for archival | 
 | use (i.e. in cases where a .tar.gz file may be used), and in constrained | 
 | block device/memory systems (e.g. embedded systems) where low overhead is | 
 | needed. | 
 |  | 
 | 1. SQUASHFS OVERVIEW | 
 | -------------------- | 
 |  | 
 | 1. Data, inodes and directories are compressed. | 
 |  | 
 | 2. Squashfs stores full uid/gids (32 bits), and file creation time. | 
 |  | 
 | 3. In theory files up to 2^64 bytes are supported. In theory filesystems can | 
 |  be up to 2^64 bytes. | 
 |  | 
 | 4. Inode and directory data are highly compacted, and packed on byte | 
 |  boundaries. Each compressed inode is on average 8 bytes in length | 
 |  (the exact length varies on file type, i.e. regular file, directory, | 
 |  symbolic link, and block/char device inodes have different sizes). | 
 |  | 
 | 5. Squashfs can use block sizes up to 1Mbyte (the default size is 128K). | 
 |  Using 128K blocks achieves greater compression ratios than the normal | 
 |  4K block size. | 
 |  | 
 | 6. File duplicates are detected and removed. | 
 |  | 
 | 7. Filesystems can be compressed with gzip, xz (lzma2), lzo or lz4 | 
 |  compression algorithms. | 
 |  | 
 | 1.1 Extended attributes (xattrs) | 
 | -------------------------------- | 
 |  | 
 | Squashfs filesystems now have extended attribute support. The | 
 | extended attribute implementation has the following features: | 
 |  | 
 | 1. Layout can store up to 2^48 bytes of compressed xattr data. | 
 | 2. Number of xattrs per inode unlimited. | 
 | 3. Total size of xattr data per inode 2^48 bytes of compressed data. | 
 | 4. Up to 4 Gbytes of data per xattr value. | 
 | 5. Inline and out-of-line xattr values supported for higher performance | 
 |  in xattr scanning (listxattr & getxattr), and to allow xattr value | 
 |  de-duplication. | 
 | 6. Both whole inode xattr duplicate detection and individual xattr value | 
 |  duplicate detection supported. These can obviously nest, file C's | 
 |  xattrs can be a complete duplicate of file B, and file B's xattrs | 
 |  can be a partial duplicate of file A. | 
 | 7. Xattr name prefix types stored, allowing the redundant "user.", "trusted." | 
 |  etc. characters to be eliminated and more concisely stored. | 
 | 8. Support for files, directories, symbolic links, device nodes, fifos | 
 |  and sockets. | 
 |  | 
 | Extended attribute support is in 2.6.35 and later kernels. Filesystems | 
 | with extended attributes can be mounted on 2.6.29 and later kernels, the | 
 | extended attributes will be ignored with a warning. | 
 |  | 
 | 2. USING SQUASHFS | 
 | ----------------- | 
 |  | 
 | Squashfs filesystems should be mounted with 'mount' with the filesystem type | 
 | 'squashfs'. If the filesystem is on a block device, the filesystem can be | 
 | mounted directly, e.g. | 
 |  | 
 | %mount -t squashfs /dev/sda1 /mnt | 
 |  | 
 | Will mount the squashfs filesystem on "/dev/sda1" under the directory "/mnt". | 
 |  | 
 | If the squashfs filesystem has been written to a file, the loopback device | 
 | can be used to mount it (loopback support must be in the kernel), e.g. | 
 |  | 
 | %mount -t squashfs image /mnt -o loop | 
 |  | 
 | Will mount the squashfs filesystem in the file "image" under | 
 | the directory "/mnt". | 
 |  | 
 | 3. MKSQUASHFS | 
 | ------------- | 
 |  | 
 | 3.1 Mksquashfs options and overview | 
 | ----------------------------------- | 
 |  | 
 | As squashfs is a read-only filesystem, the mksquashfs program must be used to | 
 | create populated squashfs filesystems. | 
 |  | 
 | SYNTAX:./mksquashfs source1 source2 ... dest [options] [-e list of exclude | 
 | dirs/files] | 
 |  | 
 | Filesystem build options: | 
 | -comp <comp>	select <comp> compression | 
 | Compressors available: | 
 | gzip (default) | 
 | lzo | 
 | lz4 | 
 | xz | 
 | -b <block_size>	set data block to <block_size>. Default 128 Kbytes | 
 | Optionally a suffix of K or M can be given to specify | 
 | Kbytes or Mbytes respectively | 
 | -no-exports	don't make the filesystem exportable via NFS | 
 | -no-sparse	don't detect sparse files | 
 | -no-xattrs	don't store extended attributes | 
 | -xattrs	store extended attributes (default) | 
 | -noI	do not compress inode table | 
 | -noD	do not compress data blocks | 
 | -noF	do not compress fragment blocks | 
 | -noX	do not compress extended attributes | 
 | -no-fragments	do not use fragments | 
 | -always-use-fragments	use fragment blocks for files larger than block size | 
 | -no-duplicates	do not perform duplicate checking | 
 | -all-root	make all files owned by root | 
 | -force-uid uid	set all file uids to uid | 
 | -force-gid gid	set all file gids to gid | 
 | -nopad	do not pad filesystem to a multiple of 4K | 
 | -keep-as-directory	if one source directory is specified, create a root | 
 | directory containing that directory, rather than the | 
 | contents of the directory | 
 |  | 
 | Filesystem filter options: | 
 | -p <pseudo-definition>	Add pseudo file definition | 
 | -pf <pseudo-file>	Add list of pseudo file definitions | 
 | -sort <sort_file>	sort files according to priorities in <sort_file>. One | 
 | file or dir with priority per line. Priority -32768 to | 
 | 32767, default priority 0 | 
 | -ef <exclude_file>	list of exclude dirs/files. One per line | 
 | -wildcards	Allow extended shell wildcards (globbing) to be used in | 
 | exclude dirs/files | 
 | -regex	Allow POSIX regular expressions to be used in exclude | 
 | dirs/files | 
 |  | 
 | Filesystem append options: | 
 | -noappend	do not append to existing filesystem | 
 | -root-becomes <name>	when appending source files/directories, make the | 
 | original root become a subdirectory in the new root | 
 | called <name>, rather than adding the new source items | 
 | to the original root | 
 |  | 
 | Mksquashfs runtime options: | 
 | -version	print version, licence and copyright message | 
 | -exit-on-error	treat normally ignored errors as fatal | 
 | -recover <name>	recover filesystem data using recovery file <name> | 
 | -no-recovery	don't generate a recovery file | 
 | -info	print files written to filesystem | 
 | -no-progress	don't display the progress bar | 
 | -progress	display progress bar when using the -info option | 
 | -processors <number>	Use <number> processors. By default will use number of | 
 | processors available | 
 | -mem <size>	Use <size> physical memory. Currently set to 1922M | 
 | Optionally a suffix of K, M or G can be given to specify | 
 | Kbytes, Mbytes or Gbytes respectively | 
 |  | 
 | Miscellaneous options: | 
 | -root-owned	alternative name for -all-root | 
 | -noInodeCompression	alternative name for -noI | 
 | -noDataCompression	alternative name for -noD | 
 | -noFragmentCompression	alternative name for -noF | 
 | -noXattrCompression	alternative name for -noX | 
 |  | 
 | -Xhelp	print compressor options for selected compressor | 
 |  | 
 | Compressors available and compressor specific options: | 
 | gzip (default) | 
 |  -Xcompression-level <compression-level> | 
 | <compression-level> should be 1 .. 9 (default 9) | 
 |  -Xwindow-size <window-size> | 
 | <window-size> should be 8 .. 15 (default 15) | 
 |  -Xstrategy strategy1,strategy2,...,strategyN | 
 | Compress using strategy1,strategy2,...,strategyN in turn | 
 | and choose the best compression. | 
 | Available strategies: default, filtered, huffman_only, | 
 | run_length_encoded and fixed | 
 | lzo | 
 |  -Xalgorithm <algorithm> | 
 | Where <algorithm> is one of: | 
 | lzo1x_1 | 
 | lzo1x_1_11 | 
 | lzo1x_1_12 | 
 | lzo1x_1_15 | 
 | lzo1x_999 (default) | 
 |  -Xcompression-level <compression-level> | 
 | <compression-level> should be 1 .. 9 (default 8) | 
 | Only applies to lzo1x_999 algorithm | 
 | lz4 | 
 |  -Xhc | 
 | Compress using LZ4 High Compression | 
 | xz | 
 |  -Xbcj filter1,filter2,...,filterN | 
 | Compress using filter1,filter2,...,filterN in turn | 
 | (in addition to no filter), and choose the best compression. | 
 | Available filters: x86, arm, armthumb, powerpc, sparc, ia64 | 
 |  -Xdict-size <dict-size> | 
 | Use <dict-size> as the XZ dictionary size. The dictionary size | 
 | can be specified as a percentage of the block size, or as an | 
 | absolute value. The dictionary size must be less than or equal | 
 | to the block size and 8192 bytes or larger. It must also be | 
 | storable in the xz header as either 2^n or as 2^n+2^(n+1). | 
 | Example dict-sizes are 75%, 50%, 37.5%, 25%, or 32K, 16K, 8K | 
 | etc. | 
 |  | 
 | Source1 source2 ... are the source directories/files containing the | 
 | files/directories that will form the squashfs filesystem. If a single | 
 | directory is specified (i.e. mksquashfs source output_fs) the squashfs | 
 | filesystem will consist of that directory, with the top-level root | 
 | directory corresponding to the source directory. | 
 |  | 
 | If multiple source directories or files are specified, mksquashfs will merge | 
 | the specified sources into a single filesystem, with the root directory | 
 | containing each of the source files/directories. The name of each directory | 
 | entry will be the basename of the source path. If more than one source | 
 | entry maps to the same name, the conflicts are named xxx_1, xxx_2, etc. where | 
 | xxx is the original name. | 
 |  | 
 | To make this clear, take two example directories. Source directory | 
 | "/home/phillip/test" contains "file1", "file2" and "dir1". | 
 | Source directory "goodies" contains "goodies1", "goodies2" and "goodies3". | 
 |  | 
 | usage example 1: | 
 |  | 
 | %mksquashfs /home/phillip/test output_fs | 
 |  | 
 | This will generate a squashfs filesystem with root entries | 
 | "file1", "file2" and "dir1". | 
 |  | 
 | example 2: | 
 |  | 
 | %mksquashfs /home/phillip/test goodies output_fs | 
 |  | 
 | This will create a squashfs filesystem with the root containing | 
 | entries "test" and "goodies" corresponding to the source | 
 | directories "/home/phillip/test" and "goodies". | 
 |  | 
 | example 3: | 
 |  | 
 | %mksquashfs /home/phillip/test goodies test output_fs | 
 |  | 
 | This is the same as the previous example, except a third | 
 | source directory "test" has been specified. This conflicts | 
 | with the first directory named "test" and will be renamed "test_1". | 
 |  | 
 | Multiple sources allow filesystems to be generated without needing to | 
 | copy all source files into a common directory. This simplifies creating | 
 | filesystems. | 
 |  | 
 | The -keep-as-directory option can be used when only one source directory | 
 | is specified, and you wish the root to contain that directory, rather than | 
 | the contents of the directory. For example: | 
 |  | 
 | example 4: | 
 |  | 
 | %mksquashfs /home/phillip/test output_fs -keep-as-directory | 
 |  | 
 | This is the same as example 1, except for -keep-as-directory. | 
 | This will generate a root directory containing directory "test", | 
 | rather than the "test" directory contents "file1", "file2" and "dir1". | 
 |  | 
 | The Dest argument is the destination where the squashfs filesystem will be | 
 | written. This can either be a conventional file or a block device. If the file | 
 | doesn't exist it will be created, if it does exist and a squashfs | 
 | filesystem exists on it, mksquashfs will append. The -noappend option will | 
 | write a new filesystem irrespective of whether an existing filesystem is | 
 | present. | 
 |  | 
 | 3.2 Changing compression algorithm and compression specific options | 
 | ------------------------------------------------------------------- | 
 |  | 
 | By default Mksquashfs will compress using the gzip compression | 
 | algorithm. This algorithm offers a good trade-off between compression | 
 | ratio, and memory and time taken to decompress. | 
 |  | 
 | Squashfs also supports LZ4, LZO and XZ (LZMA2) compression. LZO offers worse | 
 | compression ratio than gzip, but is faster to decompress. XZ offers better | 
 | compression ratio than gzip, but at the expense of greater memory and time | 
 | to decompress (and significantly more time to compress). LZ4 is similar | 
 | to LZO, but, support for it is not yet in the mainline kernel, and so | 
 | its usefulness is currently limited to using Squashfs with Mksquashfs/Unsquashfs | 
 | as an archival system like tar. | 
 |  | 
 | If you're not building the squashfs-tools and kernel from source, then | 
 | the tools and kernel may or may not have been built with support for LZ4, LZO or | 
 | XZ compression. The compression algorithms supported by the build of | 
 | Mksquashfs can be found by typing mksquashfs without any arguments. The | 
 | compressors available are displayed at the end of the help message, e.g.  | 
 |  | 
 | Compressors available and compressor specific options: | 
 | gzip (default) | 
 |  -Xcompression-level <compression-level> | 
 | <compression-level> should be 1 .. 9 (default 9) | 
 |  -Xwindow-size <window-size> | 
 | <window-size> should be 8 .. 15 (default 15) | 
 |  -Xstrategy strategy1,strategy2,...,strategyN | 
 | Compress using strategy1,strategy2,...,strategyN in turn | 
 | and choose the best compression. | 
 | Available strategies: default, filtered, huffman_only, | 
 | run_length_encoded and fixed | 
 | lzo | 
 |  -Xalgorithm <algorithm> | 
 | Where <algorithm> is one of: | 
 | lzo1x_1 | 
 | lzo1x_1_11 | 
 | lzo1x_1_12 | 
 | lzo1x_1_15 | 
 | lzo1x_999 (default) | 
 |  -Xcompression-level <compression-level> | 
 | <compression-level> should be 1 .. 9 (default 8) | 
 | Only applies to lzo1x_999 algorithm | 
 | lz4 | 
 |  -Xhc | 
 | Compress using LZ4 High Compression | 
 | xz | 
 |  -Xbcj filter1,filter2,...,filterN | 
 | Compress using filter1,filter2,...,filterN in turn | 
 | (in addition to no filter), and choose the best compression. | 
 | Available filters: x86, arm, armthumb, powerpc, sparc, ia64 | 
 |  -Xdict-size <dict-size> | 
 | Use <dict-size> as the XZ dictionary size. The dictionary size | 
 | can be specified as a percentage of the block size, or as an | 
 | absolute value. The dictionary size must be less than or equal | 
 | to the block size and 8192 bytes or larger. It must also be | 
 | storable in the xz header as either 2^n or as 2^n+2^(n+1). | 
 | Example dict-sizes are 75%, 50%, 37.5%, 25%, or 32K, 16K, 8K | 
 | etc. | 
 |  | 
 | If the compressor offers compression specific options (all the compressors now | 
 | have compression specific options except the deprecated lzma1 compressor) | 
 | then these options are also displayed (.i.e. in the above XZ is shown with two | 
 | compression specific options). The compression specific options are, obviously, | 
 | specific to the compressor in question, and the compressor documentation and | 
 | web sites should be consulted to understand their behaviour. In general | 
 | the Mksquashfs compression defaults for each compressor are optimised to | 
 | give the best performance for each compressor, where what constitutes | 
 | best depends on the compressor. For gzip/xz best means highest compression, | 
 | for LZO/LZ4 best means a tradeoff between compression and (de)-compression | 
 | overhead (LZO/LZ4 by definition are intended for weaker processors). | 
 |  | 
 | 3.3 Changing global compression defaults used in mksquashfs | 
 | ----------------------------------------------------------- | 
 |  | 
 | There are a large number of options that can be used to control the  | 
 | compression in mksquashfs. By and large the defaults are the most | 
 | optimum settings and should only be changed in exceptional circumstances! | 
 | Note, this does not apply to the block size, increasing the block size | 
 | from the default of 128Kbytes will increase compression (especially | 
 | for the xz compressor) and should increase I/O performance too. However, | 
 | a block size of greater than 128Kbytes may increase latency in certain | 
 | cases (where the filesystem contains lots of fragments, and no locality | 
 | of reference is observed). For this reason the block size default is | 
 | configured to the less optimal 128Kbytes. Users should experiment | 
 | with 256Kbyte sizes or above. | 
 |  | 
 | The -noI, -noD and -noF options (also -noInodeCompression, -noDataCompression | 
 | and -noFragmentCompression) can be used to force mksquashfs to not compress | 
 | inodes/directories, data and fragments respectively. Giving all options | 
 | generates an uncompressed filesystem. | 
 |  | 
 | The -no-fragments tells mksquashfs to not generate fragment blocks, and rather | 
 | generate a filesystem similar to a Squashfs 1.x filesystem. It will of course | 
 | still be a Squashfs 4.0 filesystem but without fragments, and so it won't be | 
 | mountable on a Squashfs 1.x system. | 
 |  | 
 | The -always-use-fragments option tells mksquashfs to always generate | 
 | fragments for files irrespective of the file length. By default only small | 
 | files less than the block size are packed into fragment blocks. The ends of | 
 | files which do not fit fully into a block, are NOT by default packed into | 
 | fragments. To illustrate this, a 100K file has an initial 64K block and a 36K | 
 | remainder. This 36K remainder is not packed into a fragment by default. This | 
 | is because to do so leads to a 10 - 20% drop in sequential I/O performance, as a | 
 | disk head seek is needed to seek to the initial file data and another disk seek | 
 | is need to seek to the fragment block. Specify this option if you want file | 
 | remainders to be packed into fragment blocks. Doing so may increase the | 
 | compression obtained BUT at the expense of I/O speed. | 
 |  | 
 | The -no-duplicates option tells mksquashfs to not check the files being | 
 | added to the filesystem for duplicates. This can result in quicker filesystem | 
 | generation and appending although obviously compression will suffer badly if | 
 | there is a lot of duplicate files. | 
 |  | 
 | The -b option allows the block size to be selected, both "K" and "M" postfixes | 
 | are supported, this can be either 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K or | 
 | 1M bytes. | 
 |  | 
 | 3.4 Specifying the UIDs/GIDs used in the filesystem | 
 | --------------------------------------------------- | 
 |  | 
 | By default files in the generated filesystem inherit the UID and GID ownership | 
 | of the original file. However, mksquashfs provides a number of options which | 
 | can be used to override the ownership. | 
 |  | 
 | The options -all-root and -root-owned (both do exactly the same thing) force all | 
 | file uids/gids in the generated Squashfs filesystem to be root. This allows | 
 | root owned filesystems to be built without root access on the host machine. | 
 |  | 
 | The "-force-uid uid" option forces all files in the generated Squashfs | 
 | filesystem to be owned by the specified uid. The uid can be specified either by | 
 | name (i.e. "root") or by number. | 
 |  | 
 | The "-force-gid gid" option forces all files in the generated Squashfs | 
 | filesystem to be group owned by the specified gid. The gid can be specified | 
 | either by name (i.e. "root") or by number. | 
 |  | 
 | 3.5 Excluding files from the filesystem | 
 | --------------------------------------- | 
 |  | 
 | The -e and -ef options allow files/directories to be specified which are | 
 | excluded from the output filesystem. The -e option takes the exclude | 
 | files/directories from the command line, the -ef option takes the | 
 | exlude files/directories from the specified exclude file, one file/directory | 
 | per line. | 
 |  | 
 | Two styles of exclude file matching are supported: basic exclude matching, and | 
 | extended wildcard matching. Basic exclude matching is a legacy feature | 
 | retained for backwards compatibility with earlier versions of Mksquashfs. | 
 | Extended wildcard matching should be used in preference. | 
 |  | 
 | 3.5.1 Basic exclude matching | 
 | ---------------------------- | 
 |  | 
 | Each exclude file is treated as an exact match of a file/directory in | 
 | the source directories. If an exclude file/directory is absolute (i.e. | 
 | prefixed with /, ../, or ./) the entry is treated as absolute, however, if an | 
 | exclude file/directory is relative, it is treated as being relative to each of | 
 | the sources in turn, i.e. | 
 |  | 
 | %mksquashfs /tmp/source1 source2 output_fs -e ex1 /tmp/source1/ex2 out/ex3 | 
 |  | 
 | Will generate exclude files /tmp/source1/ex2, /tmp/source1/ex1, source2/ex1, | 
 | /tmp/source1/out/ex3 and source2/out/ex3. | 
 |  | 
 | 3.5.2 Extended exclude file handling | 
 | ------------------------------------ | 
 |  | 
 | Extended exclude file matching treats each exclude file as a wildcard or | 
 | regex expression. To enable wildcard matching specify the -wildcards | 
 | option, and to enable regex matching specify the -regex option. In most | 
 | cases the -wildcards option should be used rather than -regex because wildcard | 
 | matching behaviour is significantly easier to understand! | 
 |  | 
 | In addition to wildcards/regex expressions, exclude files can be "anchored" or | 
 | "non-anchored". An anchored exclude is one which matches from the root of the | 
 | directory and nowhere else, a non-anchored exclude matches anywhere. For | 
 | example given the directory hierarchy "a/b/c/a/b", the anchored exclude | 
 | "a/b" will match "a/b" at the root of the directory hierarchy, but | 
 | it will not match the "/a/b" sub-directory within directory "c", whereas a | 
 | non-anchored exclude would. | 
 |  | 
 | A couple of examples should make this clearer. | 
 |   | 
 | Anchored excludes | 
 |  | 
 |  1. mksquashfs example image.sqsh -wildcards -e 'test/*.gz' | 
 |  | 
 |  Exclude all files matching "*.gz" in the top level directory "test". | 
 |  | 
 |  2. mksquashfs example image.sqsh -wildcards -e '*/[Tt]est/example*' | 
 |  | 
 |  Exclude all files beginning with "example" inside directories called | 
 |  "Test" or "test", that occur inside any top level directory. | 
 |  | 
 |  Using extended wildcards, negative matching is also possible. | 
 |  | 
 |  3. mksquashfs example image.sqsh -wildcards -e 'test/!(*data*).gz' | 
 |  | 
 |  Exclude all files matching "*.gz" in top level directory "test", | 
 |  except those with "data" in the name. | 
 |  | 
 | Non-anchored excludes | 
 |  | 
 |  By default excludes match from the top level directory, but it is | 
 |  often useful to exclude a file matching anywhere in the source directories. | 
 |  For this non-anchored excludes can be used, specified by pre-fixing the | 
 |  exclude with "...". | 
 |  | 
 |  Examples: | 
 |  | 
 |  1. mksquashfs example image.sqsh -wildcards -e '... *.gz' | 
 |  | 
 |  Exclude files matching "*.gz" anywhere in the source directories. | 
 |  For example this will match "example.gz", "test/example.gz", and | 
 |  "test/test/example.gz". | 
 |  | 
 |  2. mksquashfs example image.sqsh -wildcards -e '... [Tt]est/*.gz' | 
 |  | 
 |  Exclude files matching "*.gz" inside directories called "Test" or | 
 |  "test" that occur anywhere in the source directories. | 
 |  | 
 |  Again, using extended wildcards, negative matching is also possible. | 
 |  | 
 |  3. mksquashfs example image.sqsh -wildcards -e '... !(*data*).gz' | 
 |  | 
 |  Exclude all files matching "*.gz" anywhere in the source directories, | 
 |  except those with "data" in the name. | 
 |  | 
 | 3.5.3 Exclude files summary | 
 | --------------------------- | 
 |  | 
 | The -e and -ef exclude options are usefully used in archiving the entire | 
 | filesystem, where it is wished to avoid archiving /proc, and the filesystem | 
 | being generated, i.e. | 
 |  | 
 | %mksquashfs / /tmp/root.sqsh -e proc /tmp/root.sqsh | 
 |  | 
 | Multiple -ef options can be specified on the command line, and the -ef | 
 | option can be used in conjuction with the -e option. | 
 |  | 
 | 3.6 Appending to squashfs filesystems | 
 | ------------------------------------- | 
 |  | 
 | Running squashfs with the destination directory containing an existing | 
 | filesystem will add the source items to the existing filesystem. By default, | 
 | the source items are added to the existing root directory. | 
 |  | 
 | To make this clear... An existing filesystem "image" contains root entries | 
 | "old1", and "old2". Source directory "/home/phillip/test" contains "file1", | 
 | "file2" and "dir1". | 
 |  | 
 | example 1: | 
 |  | 
 | %mksquashfs /home/phillip/test image | 
 |  | 
 | Will create a new "image" with root entries "old1", "old2", "file1", "file2" and | 
 | "dir1" | 
 |  | 
 | example 2: | 
 |  | 
 | %mksquashfs /home/phillip/test image -keep-as-directory | 
 |  | 
 | Will create a new "image" with root entries "old1", "old2", and "test". | 
 | As shown in the previous section, for single source directories | 
 | '-keep-as-directory' adds the source directory rather than the | 
 | contents of the directory. | 
 |  | 
 | example 3: | 
 |  | 
 | %mksquashfs /home/phillip/test image -keep-as-directory -root-becomes | 
 | original-root | 
 |  | 
 | Will create a new "image" with root entries "original-root", and "test". The | 
 | '-root-becomes' option specifies that the original root becomes a subdirectory | 
 | in the new root, with the specified name. | 
 |  | 
 | The append option with file duplicate detection, means squashfs can be | 
 | used as a simple versioning archiving filesystem. A squashfs filesystem can | 
 | be created with for example the linux-2.4.19 source. Appending the linux-2.4.20 | 
 | source will create a filesystem with the two source trees, but only the | 
 | changed files will take extra room, the unchanged files will be detected as | 
 | duplicates. | 
 |  | 
 | 3.7 Appending recovery file feature | 
 | ----------------------------------- | 
 |  | 
 | Recovery files are created when appending to existing Squashfs | 
 | filesystems. This allows the original filesystem to be recovered | 
 | if Mksquashfs aborts unexpectedly (i.e. power failure). | 
 |  | 
 | The recovery files are called squashfs_recovery_xxx_yyy, where | 
 | "xxx" is the name of the filesystem being appended to, and "yyy" is a | 
 | number to guarantee filename uniqueness (the PID of the parent Mksquashfs | 
 | process). | 
 |  | 
 | Normally if Mksquashfs exits correctly the recovery file is deleted to | 
 | avoid cluttering the filesystem. If Mksquashfs aborts, the "-recover" | 
 | option can be used to recover the filesystem, giving the previously | 
 | created recovery file as a parameter, i.e. | 
 |  | 
 | mksquashfs dummy image.sqsh -recover squashfs_recovery_image.sqsh_1234 | 
 |  | 
 | The writing of the recovery file can be disabled by specifying the | 
 | "-no-recovery" option. | 
 |  | 
 | 3.8 Pseudo file support | 
 | ----------------------- | 
 |  | 
 | Mksquashfs supports pseudo files, these allow fake files, directories, character | 
 | and block devices to be specified and added to the Squashfs filesystem being | 
 | built, rather than requiring them to be present in the source directories. | 
 | This, for example, allows device nodes to be added to the filesystem without | 
 | requiring root access. | 
 |  | 
 | Mksquashfs 4.1 added support for "dynamic pseudo files" and a modify operation. | 
 | Dynamic pseudo files allow files to be dynamically created when Mksquashfs | 
 | is run, their contents being the result of running a command or piece of | 
 | shell script. The modifiy operation allows the mode/uid/gid of an existing | 
 | file in the source filesystem to be modified. | 
 |  | 
 | Two Mksquashfs options are supported, -p allows one pseudo file to be specified | 
 | on the command line, and -pf allows a pseudo file to be specified containing a | 
 | list of pseduo definitions, one per line. | 
 |  | 
 | 3.8.1. Creating a dynamic file | 
 | ------------------------------ | 
 |  | 
 | Pseudo definition | 
 |  | 
 | Filename f mode uid gid command | 
 |  | 
 | mode is the octal mode specifier, similar to that expected by chmod. | 
 |  | 
 | uid and gid can be either specified as a decimal number, or by name. | 
 |  | 
 | command can be an executable or a piece of shell script, and it is executed | 
 | by running "/bin/sh -c command". The stdout becomes the contents of | 
 | "Filename". | 
 |  | 
 | Examples: | 
 |  | 
 | Running a basic command | 
 | ----------------------- | 
 |  | 
 | /somedir/dmesg f 444 root root dmesg | 
 |  | 
 | creates a file "/somedir/dmesg" containing the output from dmesg. | 
 |  | 
 | Executing shell script | 
 | ---------------------- | 
 |  | 
 | RELEASE f 444 root root \ | 
 | if [ ! -e /tmp/ver ]; then \ | 
 | echo 0 > /tmp/ver; \ | 
 | fi; \ | 
 |  ver=`cat /tmp/ver`; \ | 
 |  ver=$((ver +1)); \ | 
 |  echo $ver > /tmp/ver; \ | 
 |  echo -n `cat /tmp/release`; \ | 
 |  echo "-dev #"$ver `date` "Build host" `hostname` | 
 |  | 
 | Creates a file RELEASE containing the release name, date, build host, and | 
 | an incrementing version number. The incrementing version is a side-effect | 
 | of executing the shell script, and ensures every time Mksquashfs is run a | 
 | new version number is used without requiring any other shell scripting. | 
 |  | 
 | The above example also shows that commands can be split across multiple lines | 
 | using "\". Obviously as the script will be presented to the shell as a single | 
 | line, a semicolon is need to separate individual shell commands within the | 
 | shell script. | 
 |  | 
 | Reading from a device (or fifo/named socket) | 
 | -------------------------------------------- | 
 |  | 
 | input f 444 root root dd if=/dev/sda1 bs=1024 count=10 | 
 |  | 
 | Copies 10K from the device /dev/sda1 into the file input. Ordinarily Mksquashfs | 
 | given a device, fifo, or named socket will place that special file within the | 
 | Squashfs filesystem, the above allows input from these special files to be | 
 | captured and placed in the Squashfs filesystem. | 
 |  | 
 | 3.8.2. Creating a block or character device | 
 | ------------------------------------------- | 
 |  | 
 | Pseudo definition | 
 |  | 
 | Filename type mode uid gid major minor | 
 |  | 
 | Where type is either | 
 | b - for block devices, and | 
 | c - for character devices | 
 |  | 
 | mode is the octal mode specifier, similar to that expected by chmod. | 
 |  | 
 | uid and gid can be either specified as a decimal number, or by name. | 
 |  | 
 | For example: | 
 |  | 
 | /dev/chr_dev c 666 root root 100 1 | 
 | /dev/blk_dev b 666 0 0 200 200 | 
 |  | 
 | creates a character device "/dev/chr_dev" with major:minor 100:1 and | 
 | a block device "/dev/blk_dev" with major:minor 200:200, both with root | 
 | uid/gid and a mode of rw-rw-rw. | 
 |  | 
 | 3.8.3. Creating a directory | 
 | --------------------------- | 
 |  | 
 | Pseudo definition | 
 |  | 
 | Filename d mode uid gid | 
 |  | 
 | mode is the octal mode specifier, similar to that expected by chmod. | 
 |  | 
 | uid and gid can be either specified as a decimal number, or by name. | 
 |  | 
 | For example: | 
 |  | 
 | /pseudo_dir d 666 root root | 
 |  | 
 | creates a directory "/pseudo_dir" with root uid/gid and mode of rw-rw-rw. | 
 |  | 
 | 3.8.4. Modifying attributes of an existing file | 
 | ----------------------------------------------- | 
 |  | 
 | Pseudo definition | 
 |  | 
 | Filename m mode uid gid | 
 |  | 
 | mode is the octal mode specifier, similar to that expected by chmod. | 
 |  | 
 | uid and gid can be either specified as a decimal number, or by name. | 
 |  | 
 | For example: | 
 |  | 
 | dmesg m 666 root root | 
 |  | 
 | Changes the attributes of the file "dmesg" in the filesystem to have | 
 | root uid/gid and a mode of rw-rw-rw, overriding the attributes obtained | 
 | from the source filesystem. | 
 |  | 
 | 3.9 Miscellaneous options | 
 | ------------------------- | 
 |  | 
 | The -info option displays the files/directories as they are compressed and | 
 | added to the filesystem. The original uncompressed size of each file | 
 | is printed, along with DUPLICATE if the file is a duplicate of a | 
 | file in the filesystem. | 
 |  | 
 | The -nopad option informs mksquashfs to not pad the filesystem to a 4K multiple. | 
 | This is performed by default to enable the output filesystem file to be mounted | 
 | by loopback, which requires files to be a 4K multiple. If the filesystem is | 
 | being written to a block device, or is to be stored in a bootimage, the extra | 
 | pad bytes are not needed. | 
 |  | 
 | 4. UNSQUASHFS | 
 | ------------- | 
 |  | 
 | Unsquashfs allows you to decompress and extract a Squashfs filesystem without | 
 | mounting it. It can extract the entire filesystem, or a specific | 
 | file or directory. | 
 |  | 
 | The Unsquashfs usage info is: | 
 |  | 
 | SYNTAX: ./unsquashfs [options] filesystem [directories or files to extract] | 
 | -v[ersion]	print version, licence and copyright information | 
 | -d[est] <pathname>	unsquash to <pathname>, default "squashfs-root" | 
 | -n[o-progress]	don't display the progress bar | 
 | -no[-xattrs]	don't extract xattrs in file system | 
 | -x[attrs]	extract xattrs in file system (default) | 
 | -u[ser-xattrs]	only extract user xattrs in file system. | 
 | Enables extracting xattrs | 
 | -p[rocessors] <number>	use <number> processors. By default will use | 
 | number of processors available | 
 | -i[nfo]	print files as they are unsquashed | 
 | -li[nfo]	print files as they are unsquashed with file | 
 | attributes (like ls -l output) | 
 | -l[s]	list filesystem, but don't unsquash | 
 | -ll[s]	list filesystem with file attributes (like | 
 | ls -l output), but don't unsquash | 
 | -f[orce]	if file already exists then overwrite | 
 | -s[tat]	display filesystem superblock information | 
 | -e[f] <extract file>	list of directories or files to extract. | 
 | One per line | 
 | -da[ta-queue] <size>	Set data queue to <size> Mbytes. Default 256 | 
 | Mbytes | 
 | -fr[ag-queue] <size>	Set fragment queue to <size> Mbytes. Default | 
 | 256 Mbytes | 
 | -r[egex]	treat extract names as POSIX regular expressions | 
 | rather than use the default shell wildcard | 
 | expansion (globbing) | 
 |  | 
 | Decompressors available: | 
 | gzip | 
 | lzo | 
 | lz4 | 
 | xz | 
 |  | 
 | To extract a subset of the filesystem, the filenames or directory | 
 | trees that are to be extracted can be specified on the command line. The | 
 | files/directories should be specified using the full path to the | 
 | files/directories as they appear within the Squashfs filesystem. The | 
 | files/directories will also be extracted to those positions within the specified | 
 | destination directory. | 
 |  | 
 | The extract files can also be given in a file using the "-e[f]" option. | 
 |  | 
 | Similarly to Mksquashfs, wildcard matching is performed on the extract | 
 | files. Wildcard matching is enabled by default. | 
 |  | 
 | Examples: | 
 |  | 
 |  1. unsquashfs image.sqsh 'test/*.gz' | 
 |  | 
 |  Extract all files matching "*.gz" in the top level directory "test". | 
 |  | 
 |  2. unsquashfs image.sqsh '[Tt]est/example*' | 
 |  | 
 |  Extract all files beginning with "example" inside top level directories | 
 |  called "Test" or "test". | 
 |  | 
 |  Using extended wildcards, negative matching is also possible. | 
 |  | 
 |  3. unsquashfs image.sqsh 'test/!(*data*).gz' | 
 |  | 
 |  Extract all files matching "*.gz" in top level directory "test", | 
 |  except those with "data" in the name. | 
 |  | 
 |  | 
 | 4.1 Unsquashfs options | 
 | ---------------------- | 
 |  | 
 | The "-ls" option can be used to list the contents of a filesystem without | 
 | decompressing the filesystem data itself. The "-lls" option is similar | 
 | but it also displays file attributes (ls -l style output). | 
 |  | 
 | The "-info" option forces Unsquashfs to print each file as it is decompressed. | 
 | The -"linfo" is similar but it also displays file attributes. | 
 |  | 
 | The "-dest" option specifies the directory that is used to decompress | 
 | the filesystem data. If this option is not given then the filesystem is | 
 | decompressed to the directory "squashfs-root" in the current working directory. | 
 |  | 
 | The "-force" option forces Unsquashfs to output to the destination | 
 | directory even if files or directories already exist. This allows you | 
 | to update an existing directory tree, or to Unsquashfs to a partially | 
 | filled directory. Without the "-force" option, Unsquashfs will | 
 | refuse to overwrite any existing files, or to create any directories if they | 
 | already exist. This is done to protect data in case of mistakes, and | 
 | so the "-force" option should be used with caution. | 
 |  | 
 | The "-stat" option displays filesystem superblock information. This is | 
 | useful to discover the filesystem version, byte ordering, whether it has a NFS | 
 | export table, and what options were used to compress the filesystem, etc. | 
 |  | 
 | Unsquashfs can decompress all Squashfs filesystem versions, 1.x, 2.x, 3.x and | 
 | 4.0 filesystems. | 
 |  | 
 | 5. FILESYSTEM LAYOUT | 
 | -------------------- | 
 |  | 
 | A squashfs filesystem consists of a maximum of nine parts, packed together on a | 
 | byte alignment: | 
 |  | 
 |  --------------- | 
 | | superblock	| | 
 | |---------------| | 
 | | compression | | 
 | | options | | 
 | |---------------| | 
 | | datablocks | | 
 | | & fragments | | 
 | |---------------| | 
 | | inode table	| | 
 | |---------------| | 
 | | directory	| | 
 | | table | | 
 | |---------------| | 
 | | fragment	| | 
 | | table | | 
 | |---------------| | 
 | | export | | 
 | | table | | 
 | |---------------| | 
 | | uid/gid	| | 
 | | lookup table	| | 
 | |---------------| | 
 | | xattr | | 
 | | table	| | 
 |  --------------- | 
 |  | 
 | Compressed data blocks are written to the filesystem as files are read from | 
 | the source directory, and checked for duplicates. Once all file data has been | 
 | written the completed super-block, compression options, inode, directory, | 
 | fragment, export, uid/gid lookup and xattr tables are written. | 
 |  | 
 | 5.1 Compression options | 
 | ----------------------- | 
 |  | 
 | Compressors can optionally support compression specific options (e.g. | 
 | dictionary size). If non-default compression options have been used, then | 
 | these are stored here. | 
 |  | 
 | 5.2 Inodes | 
 | ---------- | 
 |  | 
 | Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each | 
 | compressed block is prefixed by a two byte length, the top bit is set if the | 
 | block is uncompressed. A block will be uncompressed if the -noI option is set, | 
 | or if the compressed block was larger than the uncompressed block. | 
 |  | 
 | Inodes are packed into the metadata blocks, and are not aligned to block | 
 | boundaries, therefore inodes overlap compressed blocks. Inodes are identified | 
 | by a 48-bit number which encodes the location of the compressed metadata block | 
 | containing the inode, and the byte offset into that block where the inode is | 
 | placed (<block, offset>). | 
 |  | 
 | To maximise compression there are different inodes for each file type | 
 | (regular file, directory, device, etc.), the inode contents and length | 
 | varying with the type. | 
 |  | 
 | To further maximise compression, two types of regular file inode and | 
 | directory inode are defined: inodes optimised for frequently occurring | 
 | regular files and directories, and extended types where extra | 
 | information has to be stored. | 
 |  | 
 | 5.3 Directories | 
 | --------------- | 
 |  | 
 | Like inodes, directories are packed into compressed metadata blocks, stored | 
 | in a directory table. Directories are accessed using the start address of | 
 | the metablock containing the directory and the offset into the | 
 | decompressed block (<block, offset>). | 
 |  | 
 | Directories are organised in a slightly complex way, and are not simply | 
 | a list of file names. The organisation takes advantage of the | 
 | fact that (in most cases) the inodes of the files will be in the same | 
 | compressed metadata block, and therefore, can share the start block. | 
 | Directories are therefore organised in a two level list, a directory | 
 | header containing the shared start block value, and a sequence of directory | 
 | entries, each of which share the shared start block. A new directory header | 
 | is written once/if the inode start block changes. The directory | 
 | header/directory entry list is repeated as many times as necessary. | 
 |  | 
 | Directories are sorted, and can contain a directory index to speed up | 
 | file lookup. Directory indexes store one entry per metablock, each entry | 
 | storing the index/filename mapping to the first directory header | 
 | in each metadata block. Directories are sorted in alphabetical order, | 
 | and at lookup the index is scanned linearly looking for the first filename | 
 | alphabetically larger than the filename being looked up. At this point the | 
 | location of the metadata block the filename is in has been found. | 
 | The general idea of the index is ensure only one metadata block needs to be | 
 | decompressed to do a lookup irrespective of the length of the directory. | 
 | This scheme has the advantage that it doesn't require extra memory overhead | 
 | and doesn't require much extra storage on disk. | 
 |  | 
 | 5.4 File data | 
 | ------------- | 
 |  | 
 | Regular files consist of a sequence of contiguous compressed blocks, and/or a | 
 | compressed fragment block (tail-end packed block). The compressed size | 
 | of each datablock is stored in a block list contained within the | 
 | file inode. | 
 |  | 
 | To speed up access to datablocks when reading 'large' files (256 Mbytes or | 
 | larger), the code implements an index cache that caches the mapping from | 
 | block index to datablock location on disk. | 
 |  | 
 | The index cache allows Squashfs to handle large files (up to 1.75 TiB) while | 
 | retaining a simple and space-efficient block list on disk. The cache | 
 | is split into slots, caching up to eight 224 GiB files (128 KiB blocks). | 
 | Larger files use multiple slots, with 1.75 TiB files using all 8 slots. | 
 | The index cache is designed to be memory efficient, and by default uses | 
 | 16 KiB. | 
 |  | 
 | 5.5 Fragment lookup table | 
 | ------------------------- | 
 |  | 
 | Regular files can contain a fragment index which is mapped to a fragment | 
 | location on disk and compressed size using a fragment lookup table. This | 
 | fragment lookup table is itself stored compressed into metadata blocks. | 
 | A second index table is used to locate these. This second index table for | 
 | speed of access (and because it is small) is read at mount time and cached | 
 | in memory. | 
 |  | 
 | 5.6 Uid/gid lookup table | 
 | ------------------------ | 
 |  | 
 | For space efficiency regular files store uid and gid indexes, which are | 
 | converted to 32-bit uids/gids using an id look up table. This table is | 
 | stored compressed into metadata blocks. A second index table is used to | 
 | locate these. This second index table for speed of access (and because it | 
 | is small) is read at mount time and cached in memory. | 
 |  | 
 | 5.7 Export table | 
 | ---------------- | 
 |  | 
 | To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems | 
 | can optionally (disabled with the -no-exports Mksquashfs option) contain | 
 | an inode number to inode disk location lookup table. This is required to | 
 | enable Squashfs to map inode numbers passed in filehandles to the inode | 
 | location on disk, which is necessary when the export code reinstantiates | 
 | expired/flushed inodes. | 
 |  | 
 | This table is stored compressed into metadata blocks. A second index table is | 
 | used to locate these. This second index table for speed of access (and because | 
 | it is small) is read at mount time and cached in memory. | 
 |  | 
 | 5.8 Xattr table | 
 | --------------- | 
 |  | 
 | The xattr table contains extended attributes for each inode. The xattrs | 
 | for each inode are stored in a list, each list entry containing a type, | 
 | name and value field. The type field encodes the xattr prefix | 
 | ("user.", "trusted." etc) and it also encodes how the name/value fields | 
 | should be interpreted. Currently the type indicates whether the value | 
 | is stored inline (in which case the value field contains the xattr value), | 
 | or if it is stored out of line (in which case the value field stores a | 
 | reference to where the actual value is stored). This allows large values | 
 | to be stored out of line improving scanning and lookup performance and it | 
 | also allows values to be de-duplicated, the value being stored once, and | 
 | all other occurences holding an out of line reference to that value. | 
 |  | 
 | The xattr lists are packed into compressed 8K metadata blocks. | 
 | To reduce overhead in inodes, rather than storing the on-disk | 
 | location of the xattr list inside each inode, a 32-bit xattr id | 
 | is stored. This xattr id is mapped into the location of the xattr | 
 | list using a second xattr id lookup table. | 
 |  | 
 | 6. AUTHOR INFO | 
 | -------------- | 
 |  | 
 | Squashfs was written by Phillip Lougher, email phillip@lougher.demon.co.uk, | 
 | in Chepstow, Wales, UK. If you like the program, or have any problems, | 
 | then please email me, as it's nice to get feedback! |