Názory k článku
OpenZFS bude mít Fast Dedup

O Fast Dedup mluví v prezentaci také Allan Jude, jeden z vývojářů, pokud by se někdo chtěl podívat: https://www.youtube.com/watch?v=_T2lkb49gc8

Hodně zajímavé je, že se podle prezentace podařilo vyřešit výkonnostní škálování a obecně není propad výkonu při deduplikaci tak zásadní.

Deduplikaci jsem mnohokrát zkoušel, ale vlastně nikdy jsem se nedopracoval k takovému tomu WoW efektu...

Dejme tomu že na 100 TB úložišti to deduplikuje stovky GB, což vypadá jako něco obřího, ale jsou to GB vs 100 TB celkové kapacity, takže to není ani 1%
No a na druhé straně je určitá nenulová zátěž kladená na úložiště (RAM i IOPS) a prostor pro nějaké hnusné selhání, které by mohlo částečně probíhat i skrytě a dlouho.

Obecná deduplikace se, podle mě, nevyplatí nikdy. A pokud už víme, že k duplikaci dat bude docházet, tak lze použít mnohem cílenější techniky.

Tady mi u ZFS chybí to co má BTRFS od počátku. Tedy možnost udělat X klonů původního datasetu a ten původní dataset následně smazat. A všechny naklonované datasety od počátku sdílejí všechny datové bloky. U ZFS je tam stále ten originální dataset. V tomto je BTRFS daleko flexibilnější.

Takže na konkrétní data se víc vyplatí dělat reflinky nebo btrfs snapshoty, dle konkrétních dat.

jj, jsem stejného názoru.

Souhlas s tím, že se vyplatí cíleně, tj. mám už dopředu představu o potenciálním množství duplicitních dat. Na tohle je třeba nástroj https://github.com/markfasheh/duperemove, předhodím tomu soubory a najde do co jde zdeduplikovat. Výhody a nevýhody jsou asi zřejmé, za mě vidím hlavně ty výhody, že to můžu pustit, kdy se to hodí, inkrementální k tomu přidávat další soubory, které se zdeduplikují s původními.

Ten globální přístup k on-line deduplikaci v btrfs asi nikdy nebude. Byly nějaké předběžné verze, ale celkově to tolik zesložití IO cesty, je to v jádře (hůř se řeší okrajové stavy a konfigurace) a ten přínos je přinejmenším diskutabilní. Viz https://www.usenix.org/conference/fast11/study-practical-deduplication "A Study of Practical Deduplication", studie z praxe, IIRC vychází průměrná úspora (jen) nějakých 20%.

Nicméně globální deduplikace se dá dosáhnout i mimo kernel, viz např. https://github.com/Zygo/bees to řeší skenováním filesystému a udržováním seznamu hashů. Potřebuje to podporu od filesystému pro hledání blok -> soubor.

Tak ono záleží, co deduplikujete. Mám případy užití, kde se takhle deduplikuje polovina úložiště. A spoustu jiných, kde je to tak, jak popisujete.

Prosím velmi konkrétně, kde vám to šetří 1/2 úložiště.
Zároveň očekávám, že to má měřitelný dopad alespoň na 8TB úložišti.

Já se totiž v reálu s ničím takovým nikdy nesetkal, že by to šetřilo cokoliv s dostatečným dopadem, IMHO to je naprosto zbytečná a potenciálně nebezpečná feature. Rád se nechám přesvědčit!

Jediné úložiště, kde to mohlo šetřit, bylo například Uloz.to, kde ale neměla deduplikace smysl, tam byla přínosnější souborová deduplikace.

Konkretni zkusenost - pres 100 TB dat. Multimedia - uspora cca 3-5%, virtualy - uspora kolem 40%, dokumenty - uspora kolem 20%. Hodne zalezi co mas za data.

Co je na tom nebezpečného?

Byl bych dost nerad, kdyby mi deduplikace ztratila data, protože málo využívaná feature + OpenZFS = nastražená mina.

Jeden konkrétní případ: fotograf, který všechny fotky stáhl z foťáku vždy do nového adresáře (takže vícekrát), před úpravami vždy nakopíroval do pracovního adresáře výchozí fotku a upravené ukládal dále.
Při překopírování na disk s deduplikací byla úspora přes 60 %.
Ale uznávám, že to je opravdu zvláštní případ.;o)

Já to dělám také tak a na tohle přece stačí nějaká vhodná forma linku. Nehledě na to, že tento chaos se sám opraví po té, co se fotky zpracují a dají se do finálního úložiště. Takže v nějakém "tempu" je nepořádek, ale ten se stejně časem zpracuje, tohle přece nemá smysl deduplikovat na úrovni FS.

Pokud by v takovém připadě byl použitý cp, tak od nějaké nedávné verze to rovnou udělá reflink (na btrfs), kopie je rychá a neduplikuje data. Ovšem u fotografa bych čekal, že nejspíš použije nějaký GUI nástroj, tam to reflink nutně dělat nemusí.

Další zvláštní případ - člověk si hraje s AI, a "díky" dokonalosti Pythonu a jeho ekosystému nemá žádnou jinou možnost, než pro každou malou hloupost udělat vlastní venv, obvykle tak 2-10GB každý.

Úspora až 90% (pokud se daj na stejnej filesystém i modely, tak buď se člověk zblázní z linkování, nebo to musí pak deduplikovat taky)

Zatím to řeším prográmkem, kterej to podle hashe předělá na hardlinky, ale má to pár nevýhod (hardlink neřeší, když něco do jednoho z těch linků zapíše) a kdyby to dělal filesystém transparentně, byl by život mnohem snažší.

Uzivatelsky profily + jejich storage ... v nekterych pripadech je deduplikace i kolem 75% = z 1G to udela 250M. Oni totiz maji neodolatelny nutkani si vse z verejnych dat kopirovat "k sobe". A to i nekollikrat, takze bez problemu najdes u jednoho uzivatele i 10+ kopii tehoz.

Takze jim muzes chodit nadavat, nebo to muzes setrvale cistit rucne ... nebo jim to zdeduplikujes a pak je ti to ukradeny.

Edit: jup a samozrejme zalohovani, tam to muze byt v nekterych pripadech jeste mnohem vic, videl sem zalohovac, kde zaloha databaze mela 1TB, a ten z toho udelal radove desitky MB zmen.

20. 2. 2024, 08:33 editováno autorem komentáře

KONECNE - NetApp ma to same, na spindle podporuje jen proces, na SSD podporuje i inline, ona ve skutecnosti neni inline, ale rekneme co 10 min, interne si to udela snapshot a ten pak vycisti - deduplikuje - to same dela 3par/primera - jako primarni uloziste pro onu tabulku to pouziva SSD a pak to zvlada deduplikovat i desitky PB dat a nesezere to celou RAM.

Ale porad ma ZFS zasadni problem, chybi nastroj na opravu FS - crashne a muzete to smazat a obnovit vse ze zalohy.
Proto mam radeji BTRFS na SAN nebo md_raid5/6 a na tom BRTFS - snapshoty, snap volumy, sub volumy, komprese, dedup. a reflink .... lidi co amji RHEL kde BTRFS vykoppli, pouzivaji aspon XFS - podppruje deduplikaci a reflink.

Imho deduplikace a komprese na vmware usetri i pres 50% data, meli jsme bezne 60% - na DB kde neni zapla komprese to usetri i 80% dat, ale treba Oracle a myslim ze i DB2 podporuje interni kompresi a pak to neni treba na disk. poli - i kdyz na poli je casto rychlejsi, zase DB si to umi optimalizovat - zalezi co kdo uctuje, nektere firmy uctuji na projekty data virtulani a nektere zautcuji jen skutecne obsazena - tedy s usetrenou kompresi a deduplikaci

Logicka chyba na FS vam nepomuze kdyz mate redundantni blokova zarizeni. Tu logickou chybu budete mit prinejhorsim redundantne vsude :-) Pripadne si chybu duplikujete pres x snapshotu jako lejno na bote. A to plati i pro bloody trash filesystem.

Proto existuje _NEZAVISLE_ zalohovani. Raid na blokovem zarizeni NENI zalohovani. Kdy zalohujete po souborech.

Filozofie ZFS byla v tom ze pokud vam FS selze az takto katastrofalne, tak budto se zvladne opravit sam ze zaloznich metadat, nebo mate experta co umi ovladat zdb a nebo mate zalohy ( a sunacle vam proda zarizeni na jedno a druhe :-)). Nastroj na opravu jest zdb ale musite rozumet ZFS zevnitr. Recovery firmy dnes uz ZFS rozumi a taky ho umi obnovit. Existuje i komercni sw na obnovu.