"A ZFS-ben mostantól van beépített deduplikáció"

Fájlrendszer, NAS, storage

Ahogy arra korábban már utaltam, az IT szakma a "virtualizáció" mellé újabb gyakran ismételgetett kifejezést talált magának a "deduplikáció" személyében. A storage gyártók után a fájlrendszer fejlesztők is egyre többet foglalkoznak a témával. A ZFS fejlesztők sem mentek el szó nélkül a téma mellett. Jeff Bonwick, a Sun storage guruja blogjában arról ír, hogy már a ZFS-nek is van (blokk-szintű, szinkron) deduplikáció szolgáltatása.

( sandras74 | 2009. 11. 03., k – 20:30 )

Ha ennyire jó ez a ZFS, akkor miért nem terjed?

Mert jogilag / technikailag nehéz belerakni Solaristól különböző rendszerekbe, főleg defaultnak? Meg mert nagy erőkkel fejlesztik a Linux következő generációs fájlrendszereit? (ext4, btrfs).

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Szerintem terjed. Én pl. felraktam magamnak egy FreeBSD-re tanulás céljából.

Volt szó arról (úgy emlékszem a Dragonfly-jal kapcsolatban), hogy nyomósabban meg kéne indokolni a ritkább os-ek célját és értelmét a Linux mellett. A ZFS egy elég nyomós indok a FreeBSD mellett.

A fejlesztők azt állítják, hogy technikailag kifejezetten könnyű volt átírni a ZFS-t FreeBSD-re.

Tud-e valaki közelebbit arról, hogy áll a ZFS NetBSD-n?
--
CCC3

- Lehet venni draga storageket, amik hasonlo jokat tudnak, ill. architekturalisan is jobbak mint egy mezei server
- Egy szervert gyakrabban cserelnek egy az egyben, mint hogy uj vinyot adjanak hozza
- filrendszer szintu snapshot helyett van LVM, ill. sok esetben meg azt sem kell hasznalni, hogy legyen backupod, LVM + rezize -el szinten lehet dinamikasan valtoztatni egy kotet meretet
- .. PEBCAK , bonyolult

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

- Lehet venni draga storageket, amik hasonlo jokat tudnak, ill. architekturalisan is jobbak mint egy mezei server

Amik sok esetben egy nagy rakas loszart nem ernek.

- Egy szervert gyakrabban cserelnek egy az egyben, mint hogy uj vinyot adjanak hozza

Ez mar realisabb erv, de sok esetben nincs is szukseg nagy hattertarrra, inkabb csak raid valamely fajtajara. Ott ZFS buntet, md ahhoz kepest egy rosszul szitualt vicc.

- filrendszer szintu snapshot helyett van LVM, ill. sok esetben meg azt sem kell hasznalni, hogy legyen backupod, LVM + rezize -el szinten lehet dinamikasan valtoztatni egy kotet meretet

Ennel azert "kicsit" tobbet tud.

- .. PEBCAK , bonyolult

Ez az ev vicce. Ennel egyszerubben hasznalhato es ennyire flexibilis fs nincs masik a piacon. Kemeny 2 (ketto) darab sor osszerakni egy raid1 tombot ugy, hogy az utana automountol es nincs ket nap sync mint egy lvm+md parosnal. Kb. ennyire bonyolult barmely mas muvelet is vele.

---
pontscho / fresh!mindworkz

( zeller | 2009. 11. 03., k – 21:35 )

Buzzword rulez :) DoubleSpace, Stacker és társaira emlékszik még valaki...?

( zwei | 2009. 11. 03., k – 23:21 )

Ha neadj isten valaki tesztelné, meg tudná mondani, hogy a deduplikáció működik -e snapshotokkal is?

Azt írja a blog, hogy a teljes dataset-en működik, vagyis ha csinálok egy snapshot-ot, majd rámásolom ugyanazokat a fájlokat a fájlrendszerre, akkor nem nő jelentősen a foglalt hely?

Én is, csak nem használnám.
Még a Sol 8 idején is volt egy olyan UFS bug, amit asszem mi jelentettünk először, pedig akkor már jó pár verzión volt túl...

Az alap zfs, és a snapshotolás egész jó, több site-on használjuk, Oracle apache, tomcat meg mittomén még mi egész jól megy rajta, TSM is ismeri, stb. szóval szeressük meg minden, viszont az új fícsörökkel elég konzervatív vagyok....

( fimikz | 2009. 11. 04., sze – 09:15 )

neked tenyleg fingod sincs arrol, h mirol beszelsz :)

eloszor is, a ZFS-nel egyszerubben adminisztralhato FS-t meg eletemben nem lattam, nagysagrendekkel egyszerubb, mint az osszes tobbi.

az LVM+snapshot+grow/shrinkfs pedig egy vicc. anno mikor dolgom volt vele, LVM snapshotolni nem tudhattunk, mert volt valami operaciojaban bug, ami oopshoz vezetett.
aztan, ne felejtsd el, hogy az lvm snapshot nem az FS-t snapshotolja, hanem az alatta levo blockdevice-t. ehhez hozzavesszuk azt, hogy a binuxos csillio filerendszer egyike sem garantalja, hogy a diszken kint levo adag mindig konzisztens. ez azt jelenti, hogy a snapshotod felhasznalasa azzal kezdodik minimum, h fsck, rosszabb esetben hasznalhatatlan a snapshotod teljes mertekben, kuka.

tovabba. vegyunk egy olyan szkenariot, mikor van egy 1T-s tombod, rajta 3 FS-ed, mindegyik maximalis helyfoglalasa 500G lehet (szamoltok, ugye? 3x500>1024), de mondjuk megmondom, hogy egynek legalabb 300G helyet tartsunk fent, azt ne birjak elenni elole. ez ellen sem ved az LVM-ed.
kovetkezo dolog, csokkentsuk az FS meretet! melyikotok bizik meg teljes mertekben az LVMshrink+shrinkfs utilitikben? na? na errol van szo.
mivan, ha rajossz, h ide-oda X blockmeretre van szukseg, nem Y-ra, amivel az FS-t csinalod, kulonben csak pocsekolsz, ami bizonyos esetekben felettebb kellemetlen lehet (maildir), vagy performancia ineffektiv(RDBMS). newfs v on-the-fly atallitod? LVM vs ZFS.

stb. piciket utana kene nezni dolgoknak, mielott a szel meglengeti az arcodat. ZFS-t nem odaszartak a sarokba, mint n+1-dik FS-t a heten, teljesen veletlenul

igen. hajszal pontosan ezzel allitod be a filerendszer meretet.

a zpool pedig olyan, mint a diszkek, amibol az lvm is gazdalkodik. nem a fizikai device-ok kisebbre csereleset kerdezted, hanem a rajtuk levo filerendszer meretenek csokkenteset. en pedig arra valaszoltam.

ugyanis a rendelkezesre allo diszkeidbol csinalsz egy pool, amibol filerendszereket allokalsz, igy mukodik a zfs. az allokalt fs-ek meretet pedig a quota nevu parameter hatarozza meg.

vonatkoztass el attol, hogy amit a zfs parancs csinal, az egy "fajlrendszer".

kepzeld el azt, hogy a zfs create az igazabol egy alias az mkdir-re.

van egy teras valamid, ebben csinalsz 3 konyvtarat, es beallitasz rajuk 500-500GB tree quotat. hoppa, ilyet mashol is lehet, nem is tudom, hogy jon ide az lvm. vagy ha mar belekeverjuk az lvm-et, akkor keverjuk bele a zpool-t is, ami epp ugyanannyira tud shrinkelni, mint az, pontosabban annyira se. :)

de, illetve is.

mivel ezzel nem allokalod a helyet a filerendszernek, hanem a maximalis altala foglalhato meretet hatarozod meg.

a reserved parameter a neki fentartott hely, es azt is lehet csokkenteni-novelni, vagy kikapcsolni. es kikapcsolasnal/csokkentesnel ugyanugy barki masnak rendelkezesre all a datasetben.

zfs-nél hogy csökkented a méretet?

Eddig eszembe se jutott volna a pool méretét csökkenteni, mivel általában egy teljes fizikai eszközt kap. Mi az a usecase, ami ezt a műveletet kívánja? LVM VG-t se szoktak szerintem se növelni, se csökkenteni.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Ebben a szálban arról volt szó (ha átolvasod :), hogy miért jobb a ZFS, amikor LVM-el is lehet egy fájlrendszer méretét csökkenteni, de valamilyen különös logika szerint Mico szerint a ZPool egyenlő egy LV-vel egy LVM-ben, de véleményem szerint a ZPool egy VG-vel egyenértékű, egy ZFS pedig az LV-vel.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

"Hm... és ekkor szokták a VG méretét csökkenteni egy darab fizikai eszközön? :)"
Az nem egy fizikai eszköz, de ha az kell, itt egy másik (valós) példa 1 "fizikai" eszközzel:

Van egy darab 2T-s lun-od egy storage-ban kiajánlva a hostnak.
Az egy db 2T-s diszknek látja, és van rajta egy zpool/vg.

Szeretnéd megfelezni, hogy a felszabaduló helyből csinálhass egy másik LUN-t a storage-ban, és azt odaadhasd másik szervernek.

VG méretét csak úgy tudod csökkenteni, hogy kiveszel belőle disk-et. Ha a VG egyetlen diskből áll, értelemszerűen nem tudod csökkenteni a méretét.
Bár hozzátenném, hogy én elsősorban nem a linuxos LVM-et használom. Ott lehet, hogy már ezt is megoldották.

Ave, Saabi.

Akkor nem értem Mico-t. Majd jön és elmagyarázza talán:

fentebb LVM meg shrinkfs szívásról beszélsz. Hogyan csökkented egy zpool méretét?

Ugyanis azt nem értem, hogy miért egy LV méretének csökkentését állítja párba a pool méretének csökkentésével, amikor a zpool inkább egy VG.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Intelligens storage használata. Valamilyen rejtélyes okból a felhasználók szeretik a LUN-ok méretét változtatni újabbak létrehozása helyett. Sose értettem mire jó, de már a HP-UX is elfogadja ha egy LUN mérete hipp-hopp megváltozik.
Ez persze a növelésről szól. Hogy csökkenteni minek? Gondolom, ha már ész nélkül növelték egy LUN méretét, rájönnek hogy elfogyott a hely. Mivel egyetlen LUN-t használnak, kénytelenek annak méretét csökkenteni.

Ave, Saabi.

Hogy ne elmélet legyen csak: 


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         192     1536000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             192        6566    51200000   83  Linux
/dev/sda3            6567       30401   191454637+   f  W95 Ext'd (LBA)
/dev/sda5            9179       30401   170473716   8e  Linux LVM
/dev/sda6            6567        6632      530082   83  Linux
/dev/sda7            6633        7089     3670821   83  Linux
/dev/sda8            7090        7612     4200966   82  Linux swap / Solaris
/dev/sda9            7613        9178    12578863+  8e  Linux LVM

Szeretném az sda5-ön lévő LVM-et kettévágni, hogy tudnám megoldani?
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

( Botond | 2009. 11. 04., sze – 13:25 )

És ha SHA collision van, akkor mi van? Azért én nagyon fontos dolgokat nem bíznék a dedup-ra, még akkor se, ha csak 2^-256 az esélye, hogy egy blokkot elbukom. Mert ha egyszer bejön az a 2^-256, akkor az jó sok adatblokknyi veszteséget is okozhat, nem csak 1-et.

Így van, bele kell számolni azt is hány adatblokkod van. (Születésnap paradoxon ugye).

Ha pl. kb. 10^34,8 adatblokk van, az adatvesztés valószínűsége már ugyanannyi mint lottóötöst nyerni, lottóötöst meg nyernek az országban többen is egy évben.
Lehet te leszel a következő, már csak össze kell gyűjtened 10^34 adatblokkot.. ;)

Ez bennem is felmerult, meg is kerdeztem mar nem tudom, hol (lehet, pont itt), elmagyaraztak, hogy nem csak egy hash van, es utkozes eseten a masodlago (harmadlagos, negyedleges, stb.)hash -t hasznal. Elmeletileg ezert hash utkozes miatt nem lehet adatvesztes, mert ha utkozik a fo-hash, akkor lesz egy masodik hash is.