ZFS deduplikace a spotřeba paměti

[j]

...
Abychom se zde nedopouštěli ještě hlubších chyb, tak výchozí recordsize je na ZFS 128 KiB.
...

Tj, to bude deduplikace jak noha ... nebo jako u vmware. Kolik asi tak najdes identickych 128k bloku vs 4k.

Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.

Prave ze to hruza je, soudruzi ve vmware pouzivaj blok 1MB (a nemuzes ho zmenit), vede to pak k tomu, ze misto aby se ti zalohovalo 100MB zmen, tak se zalohuje 10GB. U databazi se velice snadno a rychle dostanes do stavu, kdy libovolnej backup = fullbackup. Pricemz realne je zmen naprosty minimum.

BTW: Nektery zalohovace pouzivaj velikost bloku plovouci.

[Reklama]

[Kit]

Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.

Prave ze to hruza je, soudruzi ve vmware pouzivaj blok 1MB (a nemuzes ho zmenit), vede to pak k tomu, ze misto aby se ti zalohovalo 100MB zmen, tak se zalohuje 10GB. U databazi se velice snadno a rychle dostanes do stavu, kdy libovolnej backup = fullbackup. Pricemz realne je zmen naprosty minimum.

BTW: Nektery zalohovace pouzivaj velikost bloku plovouci.

VMvare používá velké bloky, protože image operačních systémů bývají velké a často shodné. Šetří tím RAM.

Nevidím důvod, proč by někdo měl dávat databázi na ZFS s deduplikací. To je IMHO nesmysl. Čím primitivnější FS (nejlépe žádný), tím to databázi víc vyhovuje.

[Miroslav Šilhavý]

Tj, to bude deduplikace jak noha ... nebo jako u vmware. Kolik asi tak najdes identickych 128k bloku vs 4k.

To se mýlíte. V praxi jsou identické buďto celé soubory, nebo se neshodují vůbec. Prakticky se nezmění deduplikační poměr, náhoda, že by ve dvou souvislých řadách dat byly shodné jen vybrané bloky, je extrémně nízká.

Deduplikace se rozhodně nehodí na většinu dat, jsou to jen speciální případy.

ZFS používá deduplikaci za letu, ta je náročná na RAM a výkon. Např. NTFS používá deduplikaci, kterou provádí v nastavených intervalech (např. 1-2x denně), lze vyloučit určité typy souborů, nastavit deduplikaci na souborech starších X dní (nemá smysl ji dělat na často měnících se souborech) a provádí se nad 4k nebo 64k blocích.

Uživatel si pak musí spočítat cenu prostoru dat, cenu RAM, cenu za umístění HW (např. v racku) a odhadovaný poměr, aby se mohl rozhodnout, jestli deduplikaci zavést.

U ZFS se vyplatí přemýšlet, na kterých datasetech deup povolíte, a na kterých ne, a rozlišit, která data kam ukládáte. U NTFS máte zase jiné možnosti, ale efekt je zpožděný.

Jinak VM se zálohují pomocí technologie označování změněných bloků. Veeam Backup podporuje tzv. dedup-friendly komrpesi, kdy komprimuje zarovnaně na bloky, aby stejně zkomprimovaná data zvýšila šanci na deduplikaci. Kombinací těchto technologií zálohujete velmi lehce a s poměrně rozumnou datovou náročností.

[Pavko]

Díky všem za reakce. Dle vašich reakcí i po mých pár pokusech ZFS s dedup pro produkci vhodné není, při nešetrném vypnutí se to snaží o mount ZFS, furt to píše "A start job is running for Mount ZFS filesystems" a pak tainted:P, asi se to přes noc mountnout povede. Zkoušel jsem pro data maildirů a dedup poměr je 1,14 (blok 128k) - což se nevyplatí. Ještě udělám pokusy se "zfs set checksum=skein", verify a pak s dedup off.
Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.
Ještě jednou díky všem.

[Kit]

Pro maildir jsem kdysi úspěšně vyzkoušel ReiserFS, který umí významně šetřit místo na disku u drobných souborů. Možná by se dnes pro tento účel hodil spíše BtrFS.

[Reklama]

[Miroslav Šilhavý]

Díky všem za reakce. Dle vašich reakcí i po mých pár pokusech ZFS s dedup pro produkci vhodné není, při nešetrném vypnutí se to snaží o mount ZFS, furt to píše "A start job is running for Mount ZFS filesystems" a pak tainted:P, asi se to přes noc mountnout povede. Zkoušel jsem pro data maildirů a dedup poměr je 1,14 (blok 128k) - což se nevyplatí. Ještě udělám pokusy se "zfs set checksum=skein", verify a pak s dedup off.
Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.
Ještě jednou díky všem.

Na maildir by stálo za zvážení vyzkoušet různé typy kompresí (zfs set compression=), bude to určitě účinnější, než deduplikace. Je možné, že výkon Vám bude dostačovat i na gzip > 5, nebo naopak zjistíte, že musíte použít "jen" lz4.

[Miroslav Šilhavý]

Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.

Mohu poskytnout konkrétnější informace na FreeBSD.

[Pavko]

Jestli mohu poprosit o informaci kolik tam máte dat/charakter dat a nastavení poolu? Existují nějaké nástroje na rekonstrukci dat na ZFS? Můžete příp. i na můj e-mail: hphp@seznam.cz.
Dnes jsem zkoušel dát na ZFS svazek milion malých souborů a to je očistec (dedup on), zvlášť poslední čtvrtina. Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.


Děkuji, Pavko.

[.]

Jestli mohu poprosit o informaci kolik tam máte dat/charakter dat a nastavení poolu? Existují nějaké nástroje na rekonstrukci dat na ZFS? Můžete příp. i na můj e-mail: hphp@seznam.cz.
Dnes jsem zkoušel dát na ZFS svazek milion malých souborů a to je očistec (dedup on), zvlášť poslední čtvrtina. Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.


Děkuji, Pavko.

Kdo chce kam, pomozme mu tam.
Stále nechápete, že to není dobrý nápad, tak vám tady okopíruji výtah z manuálu:
Be warned: deduplication requires an extremely large amount of memory, and most of the space savings can be had without the extra cost by enabling compression instead.

[y,]

Pravdepodobne nechape, co ta deduplikace dela -- nekdo, kdo vi, jak je to technicky realizovane by mu to mel vysvetlit.
Moje chapani je, ze pro kazdy blok (128kB) si pamatuje hash a ten drzi v pameti. Kdyz prijde na zapis dalsi blok, zkontroluje hash a pokud najde shodny, potom obsahuje obsah. Pokud je obsah stejny, tak jenom vytvori alias na ten puvodni blok. Pokud to takto funguje (a mohu se samozrejme plest), tak se mi zda nepravdepodobne, ze by to mohlo pro maily poskytnout nejakou extra vyhodu. To komprese (protoze text) se mi zda mnohem zajimavejsi (potencialne mnohem vic odmenujici) experiment.

[RDa]

Maily maji mozna stejny obsah ale hlavicky jine a ty jsou na zacatku. Bohuzel v promenlive delce a uvazovat o deduplikaci je proto cisty nesmysl. Nekdy by to chtelo premyslet a znat trocha tu strukturu dat. Vzhledem k tomu ze jak ascii tak base64 by slo komprimovat dobre, tak pouzivej jenom on the fly kompresi (napr. zmineny ReiserFS). A dnes je taky misto docela levne - co vam brani si sestavit N*10TB pole? Jiste to bude levnejsi nez N*10GB ram

[Kit]

ReiserFS byl původně určen pro hromadu malých souborů, tedy i pro maildir. Pokud vím, tak kompresi neumožňuje.

On the fly kompresi jsem našel jen u BtrFS, který by se na ten maildir mohl nakonec hodit. Ovšem bez deduplikace, která je u mailů evidentně k ničemu.

[Miroslav Šilhavý]

Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.

Jenže ty e-maily nejsou stejné, liší se v hlavičce - tj. ten blok dat je jako celek jiný. Každá hlavička má i jinou délku, takže ani od druhého bloku se to nepotká. Proto Vám deduplikace nefunguje. To by musel někdo vymyslet dedup friendly náhradu pro maildir - např. hlavičky mailů mít v jiném souboru, než těla zpráv. Pak by byla těla zpráv, teoreticky, deduplikovatelná.

[Pavko]

Máte pravdu, hlavičky jsou jiné. U maildirů je to 50% na 50% - deduplikace poměr 1,14; komprese také 1,14. Teoreticky obojím se lze dostat na cca 1,3; ale použitím deduplikace se šíleně zpomaluje rychlost čtení i zápisu. Deduplikaci vyzkouším pro jiný typ dat a vrhnu se na zkoušení různých metod komprese a btrfs, moc děkuji za nakopnutí.
Co lze udělat s poškozeným ZFS filesystemem? Neznáte někdo opravný nástroj na ZFS?
Zase dám ozvu, Pavko.

[Sten]

Co lze udělat s poškozeným ZFS filesystemem? Neznáte někdo opravný nástroj na ZFS?

ZFS se (jako všechny checksumované filesystémy) opravuje samo, když narazí na chybu. Zkontrolovat (a opravit) všechny soubory lze pomocí scrubu. Pokud narazí na chybu, kterou opravit nedokáže, tak opravit nejde.