Squashfs 4.2 s LZMA2 už přímo v jádře

Filesystém SquashFS 4.2 je součástí Linuxového jádra už od dob verze 2.6.29, ale podpora „lepších“ kompresních formátů jako XZ (=LZMA2) vyžadovala komplexnější změny v podružných systémech kernelu a k těm došlo až celkem nedávno, konkrétně v 2.6.38.

K čemu je SquashFS?

SquashFS je komprimovaný read-only souborový systém. Nehodí se tedy pro použití přímo na diskovém oddílu, i když je jasné že i takto by se dal perfektně použít. Filesystém se nicméně nejlépe hodí pro vytváření klasických archivních souborů ala tar.gz.

Narozdíl od klasických archivů (tar, cpio, apod) umožňuje squashfs připojit obsah archovu přímo do adresářové struktury, a plně podporuje náhodný přístup (random access) k jakýmkoli datům, ať už se nacházejí na začátku, uprostřed nebo na konci filesystému. U taru je to mnohem komplikovanější, nejen že nejde namountovat, ale navíc jsou v něm data uložena sekvenčně a např. čtení dat která jsou na konci archivu vyžaduje přečtení (a případnou dekompresi) všeho od začátku. U squashfs se čte jen nutný počel bloků, které obsahují daný soubor, a mají velikost „malou“, předem danou, při vytváření filesystému. Konkrétně 64KB až 1MB.

Proč je podpora LZMA tak podstatná?

Obecně nejde o LZMA jako takové, ale o princip podporovat cokoli „lepšího“ než gzip. Kompresní algoritmus LZMA používá mnohem větší slovník, a z toho důvodu dosahuje ve většině případů lepšího kompresního poměru. A jelikož se každý bajt počítá, cokoli lepšího než gzip je tedy vítáno. Větší slovník ovšem znamená i větší spotřebu paměti RAM pro dekompresi dat; v dnešní době, kdy většina desktopů má řádově gigabajty RAM, se pár megabajtů navíc obětovat rozhodně vyplatí.

Před pár lety jsem financoval projekt squashfs-lzma, který podporu pro LZMA přinášel formou patchů pro jádro. Už tenkrát jsem udělal několik benchmarků, a vzhledem k tomu že současný mksquashfs s XZ kompresí (LZMA2) z těchtýž originálních dat vytvořil plus mínus ty samé komprimované velikosti (plus mínus: několik desítek kilobajtů, tedy rozdíl hluboko pod hranicí statistické chyby), platí defakto stejné výsledky stále, tentokrát jako benchmark současné implementace:

Benchmark

Originální data: 668 MB mksquashfs+gzip, block size = 64KB, komprimováno na 227 MB, tzn 34% originálu mksquashfs+gzip, block size 1024KB, komprimováno na 222 MB, tzn 33% originálu mksquashfs+xz, slovník = block_size = 64KB, komprimováno na 191 MB, tzn 28% originálu mksquashfs+xz, slovník = block_size = 1024KB, komprimováno na 167 MB, tzn 25% originálu

Všimněte si že mksquashfs+gzip nepodporuje nastavení velikosti slovníku.
Myslím, že defaultní maximum pro gzip je 32KB

Tvorba archivního souboru se squashfs filesystémem

Podpora v jádru je samozřejmě omezená jen na čtení, tudíž k vytvoření (zapsání) squashfs archivu budeme potřebovat mksquashfs, který je součástí squashfs tools. Stačí stáhnout zdroják, rozbalit, cd squashfs-tools, v souboru Makefile odstranit mřížku ‚#‘ na řádku s XZ_SUPPORT = 1, a pak make && make install. Kompilace bude potřebovat hlavičkové soubory XZ a GZIPu v obvyklých umístěních (např. /usr/include).

Pozor na manuálovou stránku k mksquashfs na rootu, je neaktuální a nepopisuje důležité parametry (as of today).

Komprimovaný filesystém vytvoříme takto:

root@darkstar:~# mksquashfs source1 source2 ... destfile.sq -comp xz -b 256k

kde -b udává velikost blou. Slovník má defaultně stejnou velikost, možno změnit pomocí -Xdict-size

Připojení do systému – Mount

modprobe squashfs modprobe loop mount -t squashfs -o loop /cesta/destfile.sq /mnt/neco

Uvedené první dva modprobe příkazy nemusí být nutné. Dekomprese probíhá samozřejmě transparentně, pro přístup k datům není třeba žádné rozbalování nikam na disk, filesystém se jeví jako součást adresářové struktury. Pro zajímavost doplním, že kromě mksquashfs je při kompilaci squashfs-tools přeložena také binárka unsquashfs, díky které je možné archivní filesystémy rozbalit i na strojích bez podpory v jádru, tzn obdoba tar -xf