Vlákno názorů k článku
OpenZFS bude mít Fast Dedup od CPU - Deduplikaci jsem mnohokrát zkoušel, ale vlastně nikdy jsem...

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