Offline dedup támogatás btrfs-hez

Fájlrendszer, NAS, storage

A Red Hat alkalmazásában álló Josef Bacik tegnap bejelentette offline deduplikációt btrfs-en megvalósító foltjait a linux-btrfs levelezési listán. A bejelentés szerint (el)vártak szerint működik. A fejlesztő visszajelzéseket vár az ioctl interfésszel kapcsolatban. Az userspace oldalon van még mit dolgozni, de a kernel oldala Bacik szerint elkészült. A bejelentés és a thread itt olvasható.

Azt írja, az a baj, hogy online dedupnál szar lesz az írási teljesítmény. De miért lenne az? Kiszámolod a hasht, vagy van már olyan hashű blokk, vagy nincs. Ha nincs, kiírod, és nem lassultál. Ha van, akkor a biztonság kedvéért beolvasod a blokkot, hogy tényleg egyforma-e. Az esetek 99.99...........9%-ában egyforma lesz, tehát nem kell kiírni. Vagyis írás helyett olvastál egyet, de megintcsak nem lett lassabb. Százmilliárd évben egyszer lesz egy hash ütközés, akkor kell olvasni és írni is... Szóval ezek hülye indokok, és biztos a zfs meg a többi se véletlenül csinálja így.

Egyébként meg persze, leszarhatja, szerencsére odaírta a végére, hogy ha valaki más akarja megcsinálni, hajrá. A baj inkább akkor van, ha más nem nyúlhat a forráshoz, és az author bunkósága miatt nem fejlődik a világ, a legjobb esetben forkolni lehet csak, na az olyanokat tényleg büntetni kellene.

--
joco voltam szevasz

Szerintem a probléma ott kezdődik, hogy hogyan számolunk checksumot. Nyilván az a jó, ha minél kevesebbszer nyálazzuk végig az adatot, ezért a legjobb az, ha az írás közben, amikor amúgy is végigfolyatjuk az adatot a procin, végezzük el a számítást is. Viszont ha deduplikációt akarunk, akkor már kétszer kell átnyálazni az adatot, kivéve ha duplikációt találunk. Viszont ez általában ritka.

--
Don't be an Ubuntard!

Háát az "írás közben" az sokszor jelenleg is azt jelenti, hogy: write cachebe írás közben ami csak később fog ténylegesen kiíródni, szóval a konkrét változás annyi, hogy a cache végül nem minden esetben íródik ki.

Mondjuk tény: nem tudom van-e olyan eset - vagy milyen gyakori - amikor egy blokk írása közben ugyanazon blokkot a chacheból már írják is ki vinyóra, de az intuícióm alapján az nem lehetne túl hatékony cache ami félkész blokkot is gyakran ürít...

/Persze a blokk átnyálazása mindenképp lassít, elhiszem hogy a kiírt adatmennyiségnek tényleg jócskán kell csökkennie a nyereségért.../

szerk: Persze ehhez kell blokk szinten egy cache-ból írás visszavonása. Meg egy cacheből írás felfüggesztése is, arra az esetre amikor egyezik a hash, de meg kell várni a pontos összehasonlítást is a végleges leállításhoz

Hát ez azért bonyolultabb.

"kiszámolod a hasht"

Az sha1 hash kiszámolása CPU-t fogyaszt, ha meg egyszerűbb ellenőrző kódot használsz, akkor nem 99.99...9% lesz a különbözés valószínűsége.

"vagy van már olyan hashű blokk"

Honnan tudod, hogy van-e? Onnan, hogy _keresni_ kell, vagyis egyáltalán nem csak "egyet olvastál" az írás helyett.

Amúgy nekem az egész deduplikáció ellenszenves.

--
CCC3

gondolom a valaha is kiírt vagy módosított blokkokról friss hash index-et kell tárolni, és hash egyezésnél végig olvasni mindkét blokkot hogy biztos legyen hogy egyeznek, mivel ugye semelyik hash algoritmus nem 100%.

a dedup nagy adat tárolásnál jöhet jól, ott viszont általában nem a CPU a szűk keresztm., sőt, most már a sok mag és nagy lapka cache miatt ez jobb lehet.

igazán jó lenne ha a háttértár tudna hash infót küldeni blokkonként :) (gondolom adott hash algoritmust "egyszerűen" le lehet huzalozni)

Megfelelő célhoz a megfelelő eszközt kell választani, és akkor csökkennek a problémák:

- Itt nincs szükség kriptográfiai hashre.
- Az meg nem igaz, hogy a nem kriptográfiai hash minőségű függvények kizárólag rövid, vagy annyira egyenletlen hasht tudnak generálni amivel nagyságrendekkel több lesz az ütközés.

Egyébként az ütközési valószínűségekkel jó pár nagyságrenddel a tárolókban a javíthatatlan bithiba előfordulásának valószínűsége alá mennek.

Itt egy táblázat:
http://en.wikipedia.org/wiki/Birthday_attack

Itt konkrétan azt írja, hogy 128 bitnél is 820 milliárd blokk kell, hogy a vincseszterek hibaszázalékával egy nagyságrendbe kerüljünk... Ez 4k blokkokkal 3 petabytenyi adat, 256 bitre meg valószínűleg felfoghatatlanok a nagyságrendek...

Azt azert tegyuk hozza, hogy a "javithatatlan bithibat" azonnal eszreveszi a user, hiszen a program read errort kap. Viszont deduplikacional a hash utkozes altali adat korrupciot nem feltetlen. Lehet hogy mar a backup is felulirodik mire eszreveszi vki...
Persze lehet valoszinusegeket szamolgatni, de a problema sulyossaga se egy szinten van.

Miért venné észre azonnal? Egyrészt a program lehet, hogy hónapokig, évekig nem olvassa be a bitet, másrészt mi van, ha valamilyen RAID szervezést használ, és a hiba már csak az újraépítésnél derül ki?

suckIT szopás minden nap! Itt a legújabb Intel szerver CPU-generáció, a Neon!

Elvileg ezert van az, hogy nehany raid vezerlo idonkent (alacsony terhelesnel) olvasgat a merevelemezekrol ugy, hogy mondjuk egy het alatt a vegere erjen, majd kezdi elolrol. Ezzel elerheto az, hogy egy hdd olvasasi hiba mielobb kideruljon. Ilyet nem tudom, hogy tud-e a linuxos sw raid.

Az elozo hozzaszolasom lenyege az akart lenni, hogy a hw-es hibakra mind van vmi megoldas, ami azert szuletett, hogy kikuszobolje a kart. Viszont ha egy adat sw-esen valik korruptta, az nagy gaz.

A baj inkább akkor van, ha más nem nyúlhat a forráshoz, és az author bunkósága miatt nem fejlődik a világ, a legjobb esetben forkolni lehet csak, na az olyanokat tényleg büntetni kellene.

Jól értem? A szerző volt akkora bunkó, hogy odaadta neked a forrást a négy joggal? Tényleg be kellene csukni az ilyet.

Mekkora köcsög már. Nem hajlandó az idejét, energiáját ellenszolgáltatás nélkül mások igényeire fordítani. Miatta nem fejlődik a világ.

Kötelessége lenne ingyen és bérmentve, udvariasan és kedvesen vadidegen felhasználókat kiszolgálni, levelezőlistán támogatni, patch-eket fogadni, véleményezni, beolvasztani. Ez azért a kötelessége, mert a programja néhányszori kiadásával mintegy aláírt egy örökre szóló támogatási-fejlesztési szerződést az arctalan, névtelen, pénztelen közösséggel. Erre gondolsz, ugye?

Jézusom. Vegyünk már vissza az arcunkból. A fejlesztő legfeljebb annak tartozik elszámolással, akivel szerződésre lép, és akitől pénzt (vagy ellenszolgáltatást) fogad el. Sok felhasználó valamiért abban a hitben él, hogy joguk van a fejlesztő idejét és energiáját beosztani. Hát bocs, nincs. Fizesd meg, akkor majd olyan GPL-es programot ír, ami a te kényelmedet szolgálja.

Tipp: keresd meg a NO WARRANTY szakaszt a GPL-ben. Ha ennél többet akarsz, külön megegyezés szükséges.

Második tipp: ha valaki nem terjeszti a GPL-es (nem AGPL-es) programot, akkor semmivel nem tartozik, akár ő a szerzői jog tulajdonosa, akár más. http://www.gnu.org/licenses/gpl-faq.html#NoDistributionRequirements

( STP | 2011. 01. 06., cs – 22:48 )

Én már annak is örülnék, ha a btrfs fsck-ja jól működne.

( zdesigner | 2011. 01. 06., cs – 22:51 )

"de a kernel oldala Bacik szerint elkészült"
Nem elég, hogy meg vagyok fázva, de még a HUP-on is a Bacikról olvasok! :)

( turdus | 2011. 01. 07., p – 13:09 )

"megvalósító foltjait"
ÁÁÁÁÁÁÁÁÁÁÁÁ könyörgöm trey, ne vedd át a Gyuri f*szságait... Már akkor is megmondtam neki, mikor ezt kitalálta, hogy akkor már legyen "foltozó", ne "folt", mert ez így értelmetlen...