SquashFS, aneb proč jsem neznal xz

Pod články o proudové komprimaci exportovaných dat a vytváření komprimovaného obrazu disku se rozvinula přínosná diskuse (díky za ni), kde několik lidí (a to i na G+ a FB) zmiňovalo program xz. Ačkoliv o tomto nástroji vím, přiznávám, nebral jsem jej příliš v patrnost a určitě nepatří programům, které běžně používám (možná tedy začnu). Chtěl bych vysvětlit proč.

Ani pro pracovní, ani pro soukromé účely nepotřebuji vytvářet archivy s čímkoliv. Pro soukromé účely používám git, který má data ve své vlastní (také komprimované) struktuře. Pokud potřebuji s někým tato data sdílet, stačí mu dát přístup. Posílání tarballů by situaci nezjednodušilo, právě naopak.

Pokud se jedná o zálohu dat, využíváme (to se týká spíše pracovních záležitostí) možností, které nabízí daná služba. Každý slušný program umí exportovat data v takové podobě, aby je byl schopný znovu načíst, nebo rovnou poskytuje takový export dat, nad kterým je možné rovnou pustit proces daného programu (pro příklad pg_basebackup).

Nebo exportuje data v podobě streamu, který je potom možné dále komprimovat, například export btrfs subvolume:

btrfs send jmeno_ro_subvolume | komprimator > /storage/soubor

Zde se hodí, aby komprimátor sice komprimoval, ale příliš nezdržoval. O něco větší výsledek hotový za pár minut je mnohem lepší, než o pár procent menší soubor, přičemž se export protáhne na mnoho hodin. Ne vždy je možné držet např. snapshot vm takhle dlouho.

Pro soukromé účely se mi obecné tarbally též příliš nehodí. Nepříliš dobře se s nimi pracuje, nelze je otevřít a vytáhnout jeden soubor apod (ano vím, že to jde, ale…).

Pro soukromé účely používám SquashFS což je readonly (resp. read-append) systém souborů primárně určený pro vytváření FS pro různé LiveCD a LiveUSB OS. Nic ale nebrání jej použít i pro jiný účel.

Výhody:

• Deduplikace bloků
• Mutlithread (díky rozdělení dat do bloků velmi účinné)
• Komprimace (data, metadat, bloků, lze zvolit, výchozí je komprimace všeho)
• Lze připojit jako běžný fs (readonly)
• Speciálním příkazem lze přidávat další data (která jsou opět deduplikována a to v rámci celého squashfs image, nikoliv jen daného přírůstku)

Nevýhody nevím, asi to ne úplně dobře zachází s ACL a xattr, což je mi pro soukromé soubory jedno.

Takže, kdykoliv potřebuji „uložit adresářovou strukturu do komprimovaného souboru“, udělám jednoduše:

mksquashfs adresář archiv.squash -keep-as-directory

a je to.

Přidání dalších dat do stejného archivu se dělá stejným příkazem:

mksquashfs dalšíadresář archiv.squash -keep-as-directory

Rozbalení celého archivu se dělá pomocí

unsquashfs archiv.squash

Ale to většinou není potřeba protože archiv lze kdykoliv běžně připojit jako jakýkoliv jiný fs:

mount archiv.squash mounpoint

Pokud by se cukal, tak mu lze poradit: -t squashfs -O loop,ro , ale není to potřeba.

SquashFS používám i pro zálohování BTRFS snapshotů.

Tož tak. U mě prostě není na xz, ale ani na gzip, bzip2 příliš místo. Věci jako gzip používám spíše jen ze setrvačnosti, kdykoliv je nutné vytvořit nějaký archiv. Což není příliš často. Příště si zkusím vzpomenout i na xz a dát mu šanci.