Názory k článku
Debcow pro Debian a souborové systémy s COW

Asi tomu nějak nerozumím. Ten nástroj jednak na straně serveru vytvoří speciální tar archiv, kde všechny soubory jsou zarovnané na 4k bloky. Potom se ten balíček zabalí pomocí XZ.

Při instalaci na straně klienta se ten balíček rozbalí na disk (jen do .tar souboru), ale nekopírujou na místo určení, ale jen se šachuje s blokama, takže ty soubory na disku zůstanou tam, kde jsou.

Proč se ale místo toho speciálního archivu a šachování s blokama místo toho prostě jen balíček normálně nerozbalí na stejný disk, a pak místo kopie se neudělá jen reflink na finální místo?

Něco mi uniká?

Přístup k jednomu otevřenému souboru bude obecně rychlejší než otvírat spoustu malých souboru (read i write). Předpokládám, že tam ušetří výrazné množství času, i když 6* tolik mi přijde docela dost. Pokud testovací systém měl extrémně málo paměti na cache (directory entry) nebo pomalé disky, tak možná.

Jako jiný příklad lze uvést Javovské jar soubory - čtení z jednoho archívu je výrazně rychlejší než spousta malých souborů na disku - ať už s kompresí nebo bez.

Jestli to má velký smysl, je jiná otázka - předpokládá to specificky velikost bloku, že malé soubory nebudou optimalizovány atd...

Díky, to už dává trochu smysl. Vlastně se tedy rozbalí jeden soubor a potom se pomocí chytrých triků přesvědčí filesystém, že už ten rozbalený soubor je adresářová struktura.

Furt se mi to ale zdá jako docela křehké řešení. Co když uživatel používá Btrfs s transparentní kompresí? Pak se soubor rozbalí, ale hned zase transparentně zabalí, takže to na ty bloky nevyjde. Těch kompresních algoritmů je navíc několik a člověk může nastavit stupeň komprese, takže je i těžké přizpůsobit to nějakému defaultu.

Rychlejsi to je v pripade, ze to pouzivas jako device namapovanej do ram, coz zaroven znamena, ze neresis asi tak bambiliardu veci, ktery od fs normalne ocekavas (atributy, prava ...). A pouze za predpokladu, ze resis soubory(spis desitky tisic souboru) ktery jsou mensi nez blok na HW storage.

To rozbalovani TAR archivu stylem referencovani bloku je celkem zrudnost - aneb zas nejaky rovnak na ohejbak.

Prijde mi, ze ten novej postup ani tak neresi datovy COW, ale metadatovy. Protoze klasicky by postacilo rozbalit archiv a udelat mv do cile, coz je pouze metadatova operace, pripadne cp s reflinkem, coz je znova metadatova operace.

Takze jedina uspora je, ze to namisto 2-3 metadatovych operaci pro kazdy soubor (create+move, nebo create+copyref+un­link), to udela jen jedinou (create-from-ref), plus na kazdej archiv jen 1 operace.

Takze za to uplne COW nemuze, byt jeho nasazeni pro ukladani metadat je strasne neefektivni - s kazdou upravou struktury fs se vytvari nova kopie metadat, coz znamena nutny seek. U klasickych ne-COW souboru se pouze zapsala hromada zmen do jednoho bloku (kde nahrazovala puvodni data), plus minus odskok na zurnal.

Mně asi taky něco uniká. Ptáš se, proč to nedělá to, co to dělá?

XZ se dekomprimuje do TARu a z něj se soubory "extrahují" tak, že místo kopírování sdílejí datové bloky s tím TARem. To je ten reflink.

Také se dá používat eatmydata. Čímž se dá dosáhnout toho, že dpkg při instalaci neprovádí všechny zápisy synchronně. A tím se instalace urychlí.

Takže to je kompenzace té 50. let staré .tar.gz tradice zdědené z dob ukládání a zálohování na pásky? A nebylo by třeba jednodušší zkusit to obráceně a jako .gz.tar (zabalit jednotlivé soubory a ty potom i s adresářovou strukturou slepit do taru), nebo začít používat nějaký kontejner, se kterým se pracuje pohodlněji ? :-)

Mně ten způsob reflinkování jednotlivých bloků = souborů < velikost bloku v taru přijde docela chytrý. Pokud to dobře chápu, je to vhodné specificky pro SSD, kde až tak nezáleží na defragmentaci pro čtení.