ZFS dostal podporu deduplikace

Nemam s deduplikaci zadne zkusenosti a jedna vec mi nejde do hlavy – napr. u image virtualniho stroje se muze docela lehce stat, ze se stejna data trochu pohazeji, nebo posunou (vlivem nejake fragmentace nebo tak) – a deduplikace (na urovni bloku) je v cudu, prestoze tam stejna data jsou.

Mate nekdo zkusenosti s tim, jak to vpraxi funguje? Dik.

Pokud vim tak chunky maji nejakou velikost napr. 4kB. A pak se porovnavji ruzne hashe techto chunku. Velikost je natolik mala, ze tam sice dochazi k nejakym stejnym datum,ale zase tak hrozne to neni. Pri deduplikovanych zalohach (2 mesicni retantion time OS,DB,FS i image virtualnich stroju) jsme se byli schopni dostat pod 10% mista potrebneho pro zalohu. Nekdy v docela blizke dobre by snad mel umet deduplikaci i VMware. Navic se nehodi jen pro zalohy,ale napr. cteni je z deduplikovaneho FS rychlejsi.

Je to zajímavé. Ovšem asi ne vždy vhodné použít – předpokládám, že tvorba otisků a jejich ukládání něco časově a prosotrově stojí. Navrch otisk musí být mnohem menší než ukládaná data (jinak to nemá smysl) a je otázka, jaká je pravděpodobnost kolize (různá data budou mít stejný otisk).

>> že tvorba otisků a jejich ukládání něco časově a prosotrově stojí

Mám zato, že ZFS otisky tak jako tak dělá kvůli odhalování „silent corruption“.

>> jaká je pravděpodobnost kolize

Snad by se data měla bajt po bajtu porovnat, když se rovná hash – divil bych se, kdyby to tak nedělali.

Tipnul bych si, ze autor clanku mel na mysli pripad, kdy na jednom mediu (napr. na diskovem poli) mate vice nez jednu zalohu toho jednoho a sameho.

Potom se tam vejdou zalohy treba serveru ne za posledni tyden, ale treba i za vice nez cely mesic, jelikoz stejne bloky tam budou pouze jednou.

Ovsem pri fyzickem poskozeni disku jsou data v haji prave proto, ze byla ulozena jenom jednou. Je tedy potreba pouzivat diskova pole (raidy) atd.

Je tedy potreba pouzivat diskova pole (raidy) atd. … anebo vyuzit ostatni vlastnosti zfs zpoolu :)

Anebo tak ovsem tim se ochudite o moznost minimalizovat nasledky softwarove chyby v ZFS.

Obcas se vyplati rozhodit mozne chyby mezi sfotware a hardware tak, aby se vam zniceni dat kvuli chybe hw neseslo se znicenim dat kvuli chybe sw s moznym znicenim dat kvuli chybe obsluhy.

Idealni stav: Online a Offline zalohy, vzhledem k clanku ZFS je-li to vyhodne a nejaky ten hw ci sw RAID ktery ovsem ZFS pouzivat nesmi.

Zálohovat něco na stejný filesystem/par­tition je blbost samo o sobě a vliv deduplikace už je minimální.
Ad dříve virtualizace – v rámci toho image budou knihovny, binárky atd. stejně začínat na hranici bloku. Bude-li deduplikace po blocích, tak se tedy shody najdou. Cena v případě třeba md5(4kb) bude jedno procento.
Technologie celkem zajímává, už před lety mi chybělo něco jako hardlink-copy-on-write. Nejen virtualizace, ale třeba checkout do různých míst to zlepší. Na běžném uživatelském desktopu bude užitek spíš malý.

A co když se objeví dva bloky, které mají stejné hashe, ale rozdílný obsah? To přece nikdy nelze vyloučit, ne?

a co treba hashe dvouma ruznyma metodama ?

Pokud je součet výsledné velikosti hashů menší než původní objem dat, vždy musí existovat kolize, takže to rozhodně nepomůže.

To se samozřejmě stávat bude. Určitě se to v případě stejných hashů ověří.

V pripade ze najdete shodu hashu ty bloky proste porovnate cely. Porovnat nekolik set nejvyse nekolik tisic bytu neni zase takovy problem.

Porovnavani hashu umozni rychle nalezeni shody.
Porovnani celeho obsahu znemozni chyby.

ahoj, koho zajima, jak to opravdu je, zde je link:

http://blogs.sun.com/…ry/zfs_dedup

Super, díky.

Zaujalo mě tohle:

To have a collision probability of 10⁻¹⁸ (already more reliable than almost anything else in the system), this would require approximately 2⁹⁸ unique blocks (2¹¹⁵ bytes @128k) to be written, well beyond the limits for any forseeable storage platform.

:)

prííma. uz se tesim, az nekdo najde slabinu v hashovacim algoritmu. to bude bezpecnostni dira…

Tak koukam, ze na kolize uz je pekne naslapnuto:

http://arxiv.org/abs/0803.1220

Vcelku prdel..