Az adat deduplikáció és a btrfs

Fájlrendszer, NAS, storage

Ha napjaink egyik népszerű IT divatszava "virtualizáció", akkor az elkövetkező években jó eséllyel pályázik erre a címre a "deduplikáció". Főleg ahogy a háttértárak egyre nagyobb kapacitásúak lesznek és ahogy azokon egyre több adatot tárolunk. Az adatok tárolása során nem ritka, hogy ugyanazt az adatot (adat blokkot) több példányban is tároljuk ugyanazon az adathordozón. Ez nyilvánvalóan nem szerencsés több szempontból sem. Célszerű tehát a redundáns adatokat eltávolítani és csak egy példányban megtartani. A duplikált adatok eltávolítását nevezzük deduplikációnak.

A deduplikációnak számos előnye van. Egyrészt a többszörösen tárolt adat feleslegesen foglalja a helyet, ezért a redundáns adatok eltávolításával csökken a diszk igény. A kevesebb diszk kevesebb energiát fogyaszt, kevesebb hőt termel, következésképpen kevesebb hűtést igényel. A deduplikált adathalmazt egyszerűbb menteni, kevesebb időt igényel a mentés, esélyünk lehet beleférni a mindig szűkös backup window-ba. Offsite backup esetén kevesebb adatot kell mozgatnunk, s ez jól jön ha a site-ok közt a sávszélesség korlátos. A backup-on túl olcsóbb az archiválás, nem kell annyi szalagot vásárolnunk, tárolnunk.

Deduplikáljunk. A deduplikáció lehet fájl szintű vagy blokk szintű. A fájl szintű deduplikáció során a menteni, backupolni, archiválni kívánt fájl az attribútumai alapján összehasonlításra kerül egy indexszel. Ha a fájl egyedi, akkor tárolásra kerül, az index pedig frissítésre. Ha nem egyedi (azaz már létezik), akkor csak egy, az eredeti fájlra mutató pointer kerül tárolásra.

Blokk szintű deduplikáció során az adatok blokkokra vagy chunk-okra vannak darabolva és ezeket az adatdarabokat vizsgáljuk a redundancia szempontból. Ennél az eljárásnál duplikátumok azonosításának legnépszerűbb módja az adatdarabok (például hash algoritmussal generált) egyedi azonosítókkal, lenyomatokkal való ellátása, majd ezen azonosítók, lenyomatok összehasonlítása. A vizsgálat során az adatdarab egyedi azonosítója összehasonlításra kerül a központi indexben tárolt azonosítókkal. Ha az azonosító nem szerepel a indexben, akkor az adatdarab egyedi, azaz az index frissítése mellett tárolásra kerülhet. Ha szerepel benne, az azt jelenti, hogy korábban már letárolásra került, szükségtelen újra tárolni. Ebben az esetben csak egy, az eredeti adatdarabra mutató pointer kerül tárolásra.

A btrfs levlistán is felmerült az adat deduplikáció téma. Thomas Glanzmann arról érdeklődött, hogy megvalósítható lenne-e a btrfs meglevő checksum-jainak felhasználásával a duplikált blokkok eltávolítása.

Miután Chris Mason-nel és a többi fejlesztővel megvitatták a lehetőségeket, Thomas úgy döntött, hogy elkezdi a blokk szintű deduplikáció alapjainak lerakását.

A teljes szál itt kezdődik.

( akkos v | 2009. 05. 03., v – 19:23 )

nem vagyok otthon a fájlrendszerekben, de ez van akkora változás, hogy egy esetleges brtfs2-be kerüljön csak be? Hiszen a brtfs már a mainline-ban van, szóval "közeleg" a stable (lassan)

( samuf v | 2009. 05. 03., v – 20:00 )

Azért adatbiztonság szempontjából elgondolkodtató a dolog. Ha egy block fizikailag sérül a disk-en akkor előfordulhat, hogy nem csak egy állomány megy tönkre, hanem az összes olyan amelyik tartalmazza az adott block-ot.

Pl. (bár több okból is sántít a példa, de) ha van 1000db képfájlom, ugyanolyan méretben olyan paraméterekkel, akkor nagy az esély rá, hogy a fejléc megegyezik, így azok csak egyszer lesznek tárolva. Ha ez az 1 adat block megsérül, akkor egyetlen képet sem fogom tudni megnyitni.

Adatbiztonsag szempontjabol az a legjobb, ha a redundans adatok direkt azok, es igy fel lehet oket hasznalni hibajavitasra (hexaeditor nelkul).

Pl. itt a fennmarado tarhelyen csinalhatsz (hasrautes) n+1 redundans raid helyett n+2 redundansat, igy adatbiztonsag szempontjabol meg elorebb is vagy.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( Tsab | 2009. 05. 03., v – 19:57 )

ez nem jelent így óriási cpu igénybevételt?

Ez azért kérdéses. A hash számítás azért annyira nem húzós, még így is bőven a diszk a szűk keresztmetszet. Még memórialapoknál is megcsinálható virtuális gépek között (ESX/ESXi biztosan csinál is ilyet). Én inkább ott látom a bajt, hogy a hash komparálásnál valahonnan a vinyóról kell levadászni a már meglévő hash-ek indexét, ami minimum néhány seekelés. Hash egyezésnél (ami azért szerintem nem lesz annyira nagyon ritka) ténylegesen komparálni is kell a blokkok tartalmát, ami újabb seekelés. A gyors szekvenciális transzfert garantáltan tönkreteszi, szóval inkább SSD-khez lesz jó.

Illetve hát index méret vs. hamis pozitívok száma közötti kompromisszum kérdése az egész. Ha kicsi az index, akkor folyamatosan memóriában cache-elhető, viszont sok lesz a hash ütközés. Érdekesnek mindeképpen érdekes, hogy hogyan lehet valami optimumot találni az implementációhoz.
---
Linux is bad juju.

Ha hash szerint azonos (hash utkozes, aminek valoszinusege eleve kicsi) akkor meg lehet elvileg blokk szinten az egeszet osszehasonlitani, hogy tenyleg azonos-e, ami persze nyilvan tobb eroforras de nem feltetlenul olyan hatalmas azert. Kerdes, megeri-e. Illetve megeri-e ez az egesz deduplikacio, tenyleg megnezem hany azonos blokk lehet a filerendszereimen :)

( enpassant v | 2009. 05. 03., v – 19:58 )

Annak látom értelmét, hogy megmondja melyek a duplikált fájlok és felajánlja a duplikátumok törlését vagy linkelését.
Annak viszont nem, hogy ezt automatikusan tegye (nem tudom, hogyan tervezik).
Duplikálni azért szoktunk, hogy legyen másolatunk valamiről, ha ez csak egy link, akkor nem ér az egész semmit. Pl. egy konfig állományunkat duplikáljuk (pl. /etc/X11/xorg.conf), ha megváltozna az eredeti, akkor legyen róla másolatunk. Ha ez csak egy link és változik az eredeti, akkor ezzel együtt változik a duplikátum is. Ennek így sok értelme nincs.
Nem tudom kinek milyen a fájlrendszere, de nálam sok helyet emiatt nem találna.

"Pl. egy konfig állományunkat duplikáljuk (pl. /etc/X11/xorg.conf), ha megváltozna az eredeti, akkor legyen róla másolatunk. Ha ez csak egy link és változik az eredeti, akkor ezzel együtt változik a duplikátum is. Ennek így sok értelme nincs."

Ennek tenyleg nincs, de a deduplikacio nem is igy szokott mukodni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Sot, ha az adott jogvedo szervezet anyazni fog a a gdriveokon talalhato black_knight_cam_1cd.avi miatt, akkor csak az azonos blokkokat hasznalo fileokat kell egy mozdulattal kiherelnie a googlenek, es filenevtol fuggetlenul az ossze kalozvideo torolve lesz...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( psc | 2009. 05. 03., v – 20:27 )

Szerintem, hogy ha a blokkokat hasheli, és a hash alapján dönti el, hogy duplikáció-e, akkor az úgy nem lesz jó....
SHA-512 esetén is csak 2 az 512-en féle különböző blokk lehet így.
Könnyen belátható, hogy minél nagyobb az adatmennyiség, annál valószínűbb, hogy lesz két azonos hash, amik nem azonos adatot takarnak.

Szerintem ez nem az ext4 malőrje, hanem a késleltetett allokáció tulajdonsága a felhasználástól függően...

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Azóta már kiderült, hogy csak ext4-en ez "a késleltetett allokáció tulajdonsága a felhasználástól függően". Pl brtfs-en nincs ilyen probléma...

És ekkor felmerül a kérdés, hogy ki a hülye, az összes többi fs fejlesztő és a felhasználók, vagy az ext4 fejlesztői...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

A deduplikáció sosem úgy működik, hogy a hash alapján eldönti, hogy azonos-e vagy sem, csak a cikk szövegében nincs külön kiemelve ez a részlet. A hash csak arra kell, hogy gyorsan megtalálja, hogy mely blokkok esetén merül fel egyáltalán az egyezés gyanúja, utána van azért egy komparálás is, ami alapján eldől, hogy valóban egyeznek-e. A hash számítás gyorsítása miatt egyébként többnyire SHA512-nél _lényegesen_ kissebb értékkészletű hash függyvényeket használnak, így viszonylag kicsi az index táblázat is, amiben az eddigi hash-eket és a hozzájuk tartozó blokkokat gyűjtik. Mindig egy kompromisszum kérdése, hogy mennyire költséges végigszámolni a hash-et, mennyi a hash ütközések aránya, illetve mennyire költséges egy "hamis" egyezés esetén a komparálás. Nincs rá igazából teljesen általános recept.
---
Linux is bad juju.

csak 2 az 512-en féle különböző blokk lehet így

csak :-)

A megimserhető univerzum nagyjából 13.5 milliárd fényév sugarú. Ez azt jelenti mondjuk, hogy nincs annál kiljebb tér, minden ezen belül van. Ebben a gömbben van rengeteg galaxishalmaz. Mindegyikben rengeteg galaxis. Minden galaxisban iszonyat sok csillag. Minden csillag egeszen rettenetesen sok atomból áll. Az atomok tipikusan tartalmaznak jópár elektront. Mintegy 50 milliárdszor annyi neutrínó van, mint elektron. Mennyi neutrínó van a megismerhető univerzumban?

5*10^89 = 2^298

a 2^512 egy picit több, mint ahány neutrínó van ... mintegy 2^214 -szer több.
Ha egyszer.. majd sokára.. minden neutrínóra felírunk egy adatblockot.. akkor mekkora eséllyel lesz hash ütközés az univerzumban?
0.0000000000000000000000000000000000000000000000000000000000000037%

A 512 bites hash nem üközik soha, okés?

"Mennyi neutrínó van a megismerhető univerzumban?

5*10^89 = 2^298"

Ezt mondkjuk nem értem, hogy számoltad ki a 13.5 milliárd fényévből, de mindegy.

"A 512 bites hash nem üközik soha, okés?"
Nem, nem okés. Mert ütközik.
És sokkal hamarabb, mint gondolnád.

Többieknek köszönöm a felvilágoítást, jobban utána fogok nézni a deduplikációs algoritmusoknak.
Azt hitem, pusztán a hash alapján dönt/azonosít blockokat.

A sha-512 nem rossz hash.
De nem lehetsz biztos benne, hogy nem ütközik.
Sőt, ez ajánlom átolvasásra:
http://en.wikipedia.org/wiki/Birthday_paradox
http://en.wikipedia.org/wiki/Birthday_attack

A 2^512 valóban sok lehetőség, de véges.
Adatunk meg nem csak 2^512 féle lehet.
És lehet, hogy már sok olyan adat létezik, amik ugyan azt a hash-t adják, nem tudhatod.

Matematikailg nem lehet nekimenni úgy a dolognak, hogy "az 512 bites hash nem ütközik, okés?", mivel könnyen belátható, hogy ez nem így van, hisz egy véges elemkészletű halmaz.
Ha viszont neked van igazad, és az 512 bites hash valóban nem ütközik, akkor felesleges is mindenféle deblocking fájlrendszer, meg egyéb varázslat, hisz megvan a 2 bájtos tömörítés, csak épp 512 bites! ;)

"Ha viszont neked van igazad, és az 512 bites hash valóban nem ütközik, akkor felesleges is mindenféle deblocking fájlrendszer, meg egyéb varázslat, hisz megvan a 2 bájtos tömörítés, csak épp 512 bites! ;)"

Egyedul a kitomoritessel vannak meg aprobb problemak, de folytatjuk a kutatast.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Tfh. a blokkméret 4K (2^32768) és vegyünk mondjuk egy 1T-s (268435456 blokk) disket. Szóval legfeljebb 268435456 blokkot kell megkülönböztetni. Ha nagyobb a blokkméret, még kevesebbet. log2 268435456 ~= 28.

De vegyünk mondjuk egy 1000T -s storaget, még ott is ~37,966.

SHA-512 overkill.

----------------
Lvl86 Troll

"A megimserhető univerzum nagyjából 13.5 milliárd fényév sugarú. Ez azt jelenti mondjuk, hogy nincs annál kiljebb tér, minden ezen belül van."

szerintem meg azt jelenti, hogy mai eszkozeinkkel _mi nem latunk ki ebbol_ ; ettol fuggetlenul lehet meg tovabb haladva kifele lehet ott valami, nem is szolva arrol, hogy ami tolunk 13.5Mrd fenyevre van, annak a 13.5Mrd evvel ezelotti kepet latjuk, ki tudja mi tortent arrafele azota, ha tenyleg tagul az univerzum, akkor az r=13.5 mrd.fenyev maris hibas.

A féreglyukak egyelőre csak az általános relativitáselméletből matematikailag következő elméleti konstrukciók, s mint olyanra semmi valós bizonyíték nincs. Legfőbképp, hogy az általános relativitás egyenletei singularitások esetén nem érvényesek, holott a féreglyukak jellemzően ilyen helyeken fordulnának elő. Szal. SZVSZ matematikailag megalapozott tudományos fikció.

Azert annak eleg kicsi az eselye, hogy 1) egy fereglyuk pont felenk nezzen 2) egy fenysugar beleszeduljon 3) eszleljuk ezt a fenysugarat. A fereglyuknak nincs meg az a gravitacios mezeje, amivel ezt meg tudna tenni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ettol meg nem lesz igaz az az allitas, hogy "A megimserhető univerzum nagyjából 13.5 milliárd fényév sugarú", ugyanis a teljes univerzum megismerheto, csak meg nem _tudjuk_ megismerni, hiszen a feny meg nem ert ide. A megismerheto univerzum sugara ismeretlen, a _jelenleg ismert_ univerzum sugara 13,5 milliard fenyev sugaru.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

off++
:-)

"megismerheto vilagegyetem"
"megfigyelheto vilagegyetem"
Ezt a fogalmat szakkifejezeskent hasznaljak. Arra utalva, hogy a vilagegyetem tagul (a ter tagul az anyag kozott) es ez a tagulas innen nezve tavolsaggal aranyos. (minel messzebb van, annal gyorsabban tagul). 13.5 mrd fenyev tavolsagra ez a tagulasi sebesseg a fenysebesseg, tehat ami 'annal messzebb van' onnan feny nem tud eljutni ide, tehat nem ismerheto meg.
A fenysebesseg mint abszolult felso plafon, vilagegyetem tagulasa, a neutrinok lete, es szama az egy komplex vilagmodell reszei, hiba lenne az egyiket kikapni. Termeszetesen lehetseges, hogy nincsenek is elektronok, es minden vegtelen (a sebesseg, a ter, a gravitacio, az ido), de az a komplex vilagmodell, ami eleg jol magyarazza a vilagot ahoz, hogy szamitogepet es hup.hu -t lehessen a modell alapjan epiteni, az szerint nem.
Mindegy mar.
en tenyleg csak a 2^512 extrem nagy mivoltara akartam ravilagitani.

Ket kis fuggveny setal a sivatagban, rajukripakodik a gonosz szellem, hogy allj meg, vagy lederivallak! Mire mind a ket kis fuggveny rohogorcsben tor ki, a gonosz szellem ertetlenul nez, mire az egyik valaszol, hogy hehe, en vagyok az e^x
Ki volt a masik kis fuggveny?

Röviden az a lényeg, hogy több különböző módszerrel megmérve a Hubble-állandót, és egyéb közmológiai paramézereket, hibahatáron belül egyezően ez az érték jött ki. Mert ha csak egy módszer lenne akkor persze jogos lenne, hogy csak találgatás.
A témában ajánlom figyelmedbe a következő könyvet:
John Gribbin: Az idő születése, Akkord kiadó, 2000

------------------------------------------
Desktop: AMD Athlon X2 6000+, 2GByte DDRII, Mandriva Linux 2009.1 "Spring"
Laptop: Acer Aspire 3692, Celeron M 1,6Ghz, 1,5GByte DDRI, Mandriva Linux 2009

Ha most a Hubble-állandó-ra alapozva mondjuk a 13 mrd fényévet, akkor az lehet 9-től 17-ig akármi.
(Ugye a Hubble állandó esetében a mérési pontatlanságok miatt az mondják, hogy van kb. 1% hibája - de ki tudja, hogy csak 1%-e, és emiatt a galaxisok távolságát 20-30% pontossággal tudjuk megmondani.)

Azt se felejtsük el, hogy egy időben vitatkoztak rendesen, hogy a Hubble állandó 50-e vagy 100-e.
Aztán ugye bejött a sötét anyag elmélete (ami egyáltalán nem biztos, hogy megállja a helyét, várjuk az LHC eredményeit), s megbecsülték a Hubble-állandót 54 +- 4 -re 1996-ban. Aztán újabbmérésekkelo kiegyeztek 50 körüli értékben.
97 nyarán a Hubble állandót 73 +- 14-re becsülték.

Ma ott tartunk, hogy a Hubble-állandó nem is állandó, hanem a világegyetem öregedésével arányosan csökkenő értékű "változó".
Ebből következik, hogy a világeyetem tágulása folyamatosan lassul.

Momentán 16-17 mrd évre becsülik a világegyetem korát a Hubble-állandó alapján, a legöregebb csillagokét pedig 10-13 mrd évre.

Én azt gondolom a Hubble-állandóról, hogy kellett az elméletbe egy konstans, hogy kjöjjenek a számítások, de lóf@szt sem ér. Az évek során volt már 2-től 100 ig minden. :)
Ráadásul ha kiderül, hogy nincs sötét anyag, akkor a Hubble-állandót is ki lehet dobni gyakorlatilag.

Nem tudjuk, hogy mennyi idős a világegyetem.
Még az is lehet, hogy pár ezer éve ebben az állapotában teremtették, és ősrobbanás sem volt. :)

Ez a dolog azért nem állja meg a helyét, mert a Hubble-állandó nem csak a mérésekből következik, hanem a Standard kozmológia alapegyenleteiből is. A Hubble-állandó valóban nem állandó, mert az időtöl függ. De a világegyetem a legújabb SN1a szupernóvákon végzett mérések alappján nem hogy lassulva, hanem gyorsulva átgul az Einstein-egyeneletekben megjelenő lambda kozmológiai konstans miatt. (Ami gyakrolatilag egy tiszta matematikai következménye az alapfeltevéseknek). Az általános relativitás elmélet pedig a világ egyik legpontosabban igazol elmélete, földi és kozmológiai mértékben is. A Hubble-állandó értékének a változása pedig, nem az elmélet hiányossága, egyszerűen az hogy Hubble 1929-es felfedezése óta jócskán fejlődött a csillagászat és a technika. Ha érdekel a téma, ajánlom a figyelmedbe a nem sokára elkészülő diplomamunkámat, ill. a fentebb említett könyet. Tudomásul kell venni, hogy a tudomány és az általa kapott eredmények is időről időre változnak. De ez sokszor nem az elméletek hibája, hanem a megfigyelések és a technika elégtelensége. Nyilván egy egy mérés eredményét nem kell elfogadni 100%-ban, de ha 3 különböző megfigyelés azt mondja, hogy az érték hibahatáron belül egyezik, akkor jó esélyel közel járunk az igazsághoz.
Amúgy a Hubble-áll. értéke pedig sohasem volt kettő, épp az a lényeg, hogy kezdetben nagyon magas 5000 körüli értékről csökkent a mostanira a mérések pontosítása folyamán.

------------------------------------------
Desktop: AMD Athlon X2 6000+, 2GByte DDRII, Mandriva Linux 2009.1 "Spring"
Laptop: Acer Aspire 3692, Celeron M 1,6Ghz, 1,5GByte DDRI, Mandriva Linux 2009

Tudtommal nem a bizonyítékokkal van baj, hanem a számolás pontosságával, ezért volt már mindenféle érték, de lassan azért javul a helyezet.

A 42-t régen kizárták, ami nyilvánvalóan mutatja, hogy az elfogadott elméletek hibásak... :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( NagyZ v | 2009. 05. 03., v – 22:08 )

ugyanezt implementaltam durvan ket eve az egyik helyen, fuseval, userspaceben, c++ban :)

ahova fejlesztettem. 2T storagera rafert a sokszorosa (nincs pontos adatom, mert mar nincs eles uzemben a szerver, amin hasznaltuk).

md5ot szamoltam, aztan ha volt ami egyezett, akkor sha. a cput elenyeszoen ette, a legfobb gondunk egy ido utan az volt, hogy az interruptok vittek el a cput (~gigabit kornyeke, 2x2.8as xeon, g3as(ha jol emlekszem) HP szerver), ehez kepest a progi elenyeszo volt :)

ami meg plusz erdekessege volt, hogy mysqlbe nyomta az adatokat, ami kulon szerveren volt (nem mintha annyira kellett volna neki, de azert dobott rajta) - foleg azert, hogy konnyen tudjuk adatbanyaszni.

azert c++, mert akarmit is hisztek, nem vagyok ms zealot :) mindig a feladathoz valasztom az eszkozt. Cben irtam volna, csak a caching is kellett bele, erre kenyelmes volt az stl (map<>), nem kellett nekem szivni a kerek feltalalasaval :)

a monot most is kerulnem, ha kellene. c# 3.5 / .net 3 nagyon kiraly - kliens oldalra. szerver oldalra meg mindig nem valasztanam, arra inkabb Spring/Java EE (tudomtudom, most meg Sun berenc vagyok...)

( Nickname | 2009. 05. 03., v – 22:39 )

Ennél csak az a kínosabb, ha otthon az asszony inhome local striptease-ét, amit te veszel fel és teszel fel a netre kiderül, hogy más által máskor jópár évvel előtted már felkerült oda (és csak egy pointer leszel :)), és csak azon tűnődsz, hogy ki tudod-e tapogatni a csatlakozókat magadon vagy keresed a laggoló fekete macskát vagy mégiscsak a másik pirulát kellet volna választani. Tény, hogy a decentralizálás (redundancia) és a deduplikáció egymás ellen dolgoznak, de talán az lenne a legjobb ha mindez particiónként állítható lenne.

( uid_1526 | 2009. 05. 04., h – 09:20 )

Ez egy nagyon hatékony módszernek tűnik az állományok töredezetté tételéhez.

( djsmiley v | 2009. 05. 04., h – 09:30 )

Hülye kérdés, de nem létezik erre offline megoldás akármilyen más fs-re?

Igazából arra gondolok, hogy egy olyasmi offline megoldás ami mondjuk használható egy linuxos fájlszerveren pl. cron-ból éjszakánként.
A kereskedelmi megoldásokat nagyjából ismerem, IBM is mostanában erősít ezen a téren, sőt kitaláltak vmi cuccot ami állítólag jobb a hash-elős megoldásnál és kevesebb performacia vesztést okoz inline módban. Láttam is, nem rossz, de nekem igazából elég lenne valami "gagyi" verzió is.
Tudod, amikor egy xls megvan Micikénél, Picitikénél, Józsikánál, stb., erre keresek vmi megoldást.
Azért gondolok az offline megoldásra mert tulajdonképp annyira nem fontos és nem feszegetjük a több T adatmennyiséget, de szeretem a maximumot kihozni a lehetőségekhez mérten.

Sajnos a blockszintu deduplikaciohoz univerzalis block mapping tabla kell az filesystem lelkebe, ami ha nincs benne, nem fogjak emiatt belerakni.

Single-user kornyezetben inkabb egy ketszintu tarolasi eljarasnak volna ertelme (a nagyvallalati piacon szinten van ilyen megoldas) nem tudok neki nevet, igy nez ki:

A file-nek ket allapota van (metadata jegyzi) online/shelved. Ha online, akkor a file ott van a helyen, a filesystemben, a szokasos modon, ha selved, akkor valahol masutt. Amikor nagyon sokaig nem nyulsz egy filehoz, akkor egy userspace processz kirakhatja a polcra (shelved), ha hozzanyulsz, akkor a kernel megkeri a userspace processzt, hogy ugyan mar hozza vissza a polcrol. Alkalmazas szamara transzparens, csak a shelved statuszu file-ok megnyitasa lassabb. Ez a 'polc' ez lehet barmi. Kitalalt megoldasok, a polc szerint: valami network (lassu) meghajto; szalagos egyseg (hierarchical storage systems), lassabb diszk, vagy gzippelt helyben/masik particion. Ez a funkcio sokkal konnyebben hozzagyogyithato egy barmilyen filesystemhez, felteve, ha abban egyaltalan van userkonfiguralhato metaadat.
Egy gzippel altalaban tobbet ersz, mint blockszintu adatdeduplikacioval.
Erre sem tudok mukodo linuxos megoldast, ha valakinek van rola tudomasa, megkoszonnem.

( egeresz | 2009. 05. 04., h – 11:00 )

Egyenlore, mint uzemelteto, mar attol is boldog lennek, ha volna egy ~ 30e felhasznalora meretezheto imap szerver, ami ha egy korlevel, benne egy 10megas csatolt media tartalommal szetmegy 3000 usernek, akkor az csak egyszer van letarolva fizikailag.
(szolj, ha van).

Az adatdeduplikacio mehet bit szinten, ezek a hagyomanyos tomoritok. Mehet block szinten, errol van ebben a vitaszalban szo. Mehet file szinten, bizonyos ertelemben ezt csinalja az rsync, es mehet alkalmazas-specifkus szinten, lasd a fenti kivansagomat. Mindegyiknek van helye es ertelme.

Azokban a filesystemekeben, ahol az adattarolas teljes map-tabla alapjan megy/mehet, vagyis ahol a virtualis block -> logikai block kozotti lekepezes barmi lehet, ott egy ilyen funkcio (hasonloan a filesystemen beluli snapshothoz) nem elkepzelhetetlen. Ilyen pl a linuxos LVM2, a netapp-féle wafl, a hiradasok szerint sun oracle zfs, a linuxos btrfs, vmware vmfs. (aki szerint a linuxos LVM2 nem illik ide, az rossz vitaszalat olvas).

Vegul is, egy snapshot is adatdeduplikacio elven megy, azzal a konnyitessel, hogy nem kell megkeresnie, hogy mik az egyezo blockok, mert tortenetileg tudja. De milyen jo volna mar, ha egy kesobbi rw snapshotban a user visszair egy eredetivel megegyezo blockot, akkor erre rajonne a rendszer, es nem vesne fel?

"Egyenlore, mint uzemelteto, mar attol is boldog lennek, ha volna egy ~ 30e felhasznalora meretezheto imap szerver, ami ha egy korlevel, benne egy 10megas csatolt media tartalommal szetmegy 3000 usernek, akkor az csak egyszer van letarolva fizikailag.
(szolj, ha van)."

Azt hiszem az ilyet Exchange-nek hívják.(és lehet IMAP- szerverként is használni)

( egeresz | 2009. 05. 04., h – 11:19 )

Az adatdeduplikacio es a fragmentacio kerdeskore.

A mai diszkek, diszkalrendszerek single-user teljesitmenye csunyan leromlik a fragmentacio novekedesevel. Elsosorban azert, mert a fej sokkal lassabban mozog, mint ahogy egyebkent a diszk olvas/ir. (az SSD nem romlik le). Jol elvarhato, hogy lehetoleg minel inkabb keruljuk el a fragmentaciot.
Ha van egy filesystem, vagy egy storage rendszer, ami adatdeduplikaciot csinal, akkor igen, ez az olvasasi teljesitmeny csokkenesehez vezet(het). Meg szerencse, hogy a single user kornyezetben elenyeszo az olyan eset, hogy ket adatblock a diszken megegyezik, es az adatdeduplikacio eletbe lep.

Multi user kornyezetben ez vastagon elofordulhat, peldaul ott, amikor kulonbozo userek is rendelkeznek azonos tartalommal, de leginkabb ott, ahol rendszeres menteseket keszitenek. Vagy ott, ahol rendszeresen snapshotolnak. De a snapshotra termeszetszeruleg van deduplikacios megoldas, pont ez a lenyege annak. Multi user kornyezetben viszont nagyon gyakran szinte csak random (fragmentalt) io van, leven ha egyszerre 300 user olvassa szekvencialisan a sajat adatait, az a diszk szerint mar erosen random. Multi user kornyezetben emiatt nem faj annyira a deduplikacio miatti fragmentacio. Ahol meg megis, ott nem kell bekapcsolni. (a valasztas. az a kulcs, hogy legyen valasztas).

A mentesek es a deduplikacio kapcsolatarol:
A periodikus mentesek jelentos resze ugyanaz. A mentesek ilyeniranyu elszemtelenedese ellen jott letre az "inkrementalis backup" nevu intezmeny, ami az elmult full backup ota (vagy az utolso incre backup ota) tortent valtozasokat jegyzi fel. Nevezzuk ezt az adatduplikacio preventiv (az esemeny elott torteno) megelozesenek. Azonban senki nem szereti az evek ota halmozott incre backupokat, jo erzes idorol-idore kesziteni egy fullt. Mondjuk a szokas az hetente egy full, es naponta egy incre. Ha egy evig orizgetjuk a backupokat, ez mar 52 darab nagyreszt azonos adat. Jo volna egy esemeny utani deduplikacio is, ilyenkor lehetne kesziteni egy konzisztens mentest, aminek josaga nem fugg attol, hogy az elozo mentesek el lettek-e szurva. Es a mentes elvegzese utani deduplikacio (differenciakeszites, tomorites) igy sokkal jobb erzessel teheto meg.
Na, pont ez az a felhasznalasi modszer, ahol az adatdeduplikacioval a legtobbet lehet nyerni, es ahol a fragmentacio a legkevesebb gondot okozza. Es pont ez a piaci szegmens, ahol vannak is erre letezo, megvasarolhato termekek. Egy d2d (disk to disk) mentesi rendszert kepzelj el (az oprendszer/alkalmazas szalagnak hiszi, de a vegen egy rakas diszk van), ahol az eszkoben levo szoftver kepes deduplikaciot vegezni.
A d2d eszkozok dragak.
Az adatdeduplikacioert kulon kell fizetni altalaban, nem is keveset.

Jo volna na, egy sufniban osszerakhato hasonlo funkcionalitas, hajra btrfs, ha engem kerdezel.