SQUASHFS 4.4 - A squashed read-only filesystem for Linux Copyright 2002-2019 Phillip Lougher Released under the GPL licence (version 2 or later). Welcome to Squashfs version 4.4. 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/zstd 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, lz4 or zstd compression algorithms. 1.1 Introducing reproducible builds ----------------------------------- Ever since Mksquashfs was parallelised back in 2006, there has been a certain randomness in how fragments and multi-block files are ordered in the output filesystem even if the input remains the same. This is because the multiple parallel threads can be scheduled differently between Mksquashfs runs. For example, the thread given fragment 10 to compress may finish before the thread given fragment 9 to compress on one run (writing fragment 10 to the output filesystem before fragment 9), but, on the next run it could be vice-versa. There are many different scheduling scenarios here, all of which can have a knock on effect causing different scheduling and ordering later in the filesystem too. Mkquashfs doesn't care about the ordering of fragments and multi-block files within the filesystem, as this does not affect the correctness of the filesystem. In fact not caring about the ordering, as it doesn't matter, allows Mksquashfs to run as fast as possible, maximising CPU and I/O performance. But, in the last couple of years, Squashfs has become used in scenarios (cloud etc) where this randomness is causing problems. Specifically this appears to be where downloaders, installers etc. try to work out the differences between Squashfs filesystem updates to minimise the amount of data that needs to transferred to update an image. Additionally, in the last couple of years has arisen the notion of reproducible builds, that is the same source and build environment etc should be able to (re-)generate identical output. This is usually for verification and security, allowing binaries/distributions to be checked for malicious activity. See https://reproducible-builds.org/ for more information. Mksquashfs from release 4.4 now generates reproducible images by default. Images generated by Mksquashfs will be ordered identically to previous runs if the same input has been supplied, and the same options used. 1.1.1 Dealing with timestamps Timestamps embedded in the filesystem will stiil cause differences. Each new run of Mksquashfs will produce a different mkfs (make filesystem) timestamp in the super-block. Moreover if any file timestamps have changed (even if the content hasn't), this will produce a difference. To prevent timestamps from producing differences, the following new Mksquashfs options have been added. 1.1.2 -mkfs-time