Komprese zstd pro souborový systém Btrfs je v jádře již více než rok od 4.14. Zavaděč Grub však tuto kompresi doposud neuměl, což neumožňovalo zstd na /, nebo bylo potřeba oddělený /boot.
V pondělí byl přidán patch s podporou zstd. Nyní je potřeba jen počkat, až se změna dostane do distribucí, případně sami kompilovat. Poslední stabilní Grub 2.02 je z dubna 2017.
(zdroj: phoronix)
no to je právě dobře, že se nemění, ne?
s poškozením nemá komprese moc společného, pokud teda nepotřebujete jádra <4.14
a třeba na SSD se hodí každá úspora
takze zaplatujeme ruzne cpu bugy ktere snizi vykon o 100% a pak do toho jeste zapneme kompresi aby ten vykon nahodou nebyl vic nez potrebujeme... a to se vyplati... priste muzou pridat treba kompresi zpaq aby to melo maximalni efekt...
Co asi typicky bude pri bootu vetsi limit - propustnost disku nebo vykon CPU?
Kristabohajeho, komprese na root svazek ? Proc ?
Protože se to hodí. Nemusíte přemýšlet, jestli bootloader umí takovou věc.
Něco podobně otravného je na ZFS a FreeBSD, tam taky na boot datasetu nemůžete mít kompresi (resp. myslím, že můžete mít jen jednu konkrétní)... Otravné je na to myslet a mít kvůli pitomému zavádění systému extrabuřty. Kompresi, deduplikaci, vícenásobné uložení dat apod. řeším u oblastí s daty, ale u všeho musím pamatovat na tuhle výjimku.
Proto je dobré, aby loader uměl co nejvíc funkcí souborového systému.
Na embedded systémech (kde Linux narozdíl od desktopů, o kterých píšete, totálně dominuje) je každý megabyte drahý. Jestli díky kompresi můžu na desku dát místo 64Mb SPI flashe pinově kompatibilní 32Mb náhradu, ušetřil jsem právě $0.5 a tím zdvojnásobil OEM marži.
Běžně používáme komprimované ramdisky, ale to se musí potom vejít do RAM, že. Proto je hlad po blokové kompresi, která je prostorově nenáročná jak v RAM, tak v úložišti. Squashfs a erofs je většinou řešením, ale čím dál častěji potřebujeme read-write kvůli updatům firmware a kryptografii.
CPU bottleneck není, i nejlacinější i.MX6UUL jede na 500+ MHz, nemám šanci ho saturovat.
