ZFS vagy btrfs vagy más?

Linux-haladó

Sziasztok!

Levelezőszerver IMAP mappáinak tárolására szeretnék megfelelő fájlrendszert találni.

Az alaphelyzet:
- OS: CentOS vagy Scientific Linux 6
- Levelezőrendszer: előreláthatólag Zimbra, tehát Cyrus IMAP
- kb 130 mailbox
- 2 db 3 TB-os HDD lenne tükörbe rakva

Amit szeretnék, ha tudná a fájlrendszer:
- egy mappában kismillió apró szövegfájl kezelése
- tudjon online tömöríteni
- esetleg deduplikálni (online v offline)
- mindenképp stabil legyen, nem szeretnék adatvesztést (mentés lesz, de akkor sem)
- nem hátrány ha a fentiek ellenére gyors/nem túl lassú

Tisztában vagyok vele, hogy a btrfs-nek nincs stabil változata hivatalosan, de több olyan hozzászólást olvastam már hogy ennek ellenére nem instabilabb másoknál. Nem tudom megítélni, én még nem használtam.

Előre is köszönöm a válaszokat!

  • 7860 megtekintés

( AiRLAC v | 2013. 12. 05., cs – 13:35 )

ZFS on Linux már stabilnak mondható. Dedup felejtős hacsak nincs csilliógigabájt ramod, tömörítés mehet. Tükör jó ötlet, később rakhatsz még egy tükröt aztán mehet a stripe.

Mert az ugyanolyan adatvesztést okoz, ha a cache ssd pusztul meg.
Van egy haver, aki kinnti szállodában rg, nála zfs tömmbe van szervezve 4-8 lemez, van 2 ssd cache tükörbe, oszt jó sok kamera nyomja rá az anyagot. Azt mondja, h egész komoly storage cuccok lehasaltak a sok I/O művelettől, ez a freenas cucc a fennti cuccokkal meg simán bírja.

Hat ne hasznalj 19-es verzio alattit:)
Nem is tudom, miert tenne vki ilyet egy uj telepites eseten.

zpool vesztessel amugy nem hiszem, h jar, legfeljebb ott vigyorog butan es hasznalhatatlanul. De sosem probaltam.

A lenyeg, h ha a zil device meghal es a gep kozben mukodik tovabb, akkor meg mukodnie kell a dolgoknak rendben.

Ezen egyebkent a zfs levlistan mindig kiakadnak. A zil meg a log device nem ugyanaz. A zil akkor is van, ha nincs log device a rendszernek kulon megadva. Igy a zil (log) device lenyegeben csak irasi muveleteket kap csak, csak akkor olvassa a rendszer, ha szukseges (= recovery eseten crash utan).

t

( tompos v | 2013. 12. 05., cs – 16:20 )

> Levelezőrendszer: előreláthatólag Zimbra, tehát Cyrus IMAP

Nem cyrus

> esetleg deduplikálni (online v offline)

A btrfs tud offline (de nem block szinten, csak file szinten), egesz pontosan van hozza tool, amivel megoldhato. A zfs tud online is, de nem eri meg. Ha ssd-d lenne, akkor igen, de a HDD annyira olcso, h gyakorlatilag csak veszteni tudsz vele. Vannak a dedup-nak ezen kivul veszelyei is, nem igazan kiforrott.

> nem hátrány ha a fentiek ellenére gyors/nem túl lassú

Adj neki megfelelo mennyisegu (~lehetoleg sok) ram-ot, a cache-t rakd zram-ra, rakja ala log device-t ssd-bol, ha teheted.

> Tisztában vagyok vele, hogy a btrfs-nek nincs stabil változata hivatalosan, de több olyan hozzászólást olvastam már hogy ennek ellenére nem instabilabb másoknál. Nem tudom megítélni, én még nem használtam.

En igen, vegyes erzesekkel. Mivel mar megegettem magam, kicsit felek tole. Vannak hianyossagai, de ugy tippelem, h mondjuk 98%, h nem lesz belole gondod.
A ZFS-nek is vannak, de azok jobbara nem az adat karara vannak.

udv,
tompos

A deduplikálás jóhogy blokk szinten van. Az a deduplikáló, amire te gondolsz, és egyező tartalomnál reflink et csinál belőle, az egy nem túl szép megoldás, mindenesetre file rendszer szinten blokk szintű deduplikálás van. Elvileg 3.12 től van integrálva online deduplikáció, de nem tudok nyilatkozni még, bár futtatok 3.12-t, nem néztem, vagy nem használtam mount opciót erre (utána fogok olvasni)

"Another committed feature for Btrfs in Linux 3.12 is de-duplication (dedup) support while the file-system is mounted and active but not being done inline during file I/O operations. " http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk

Én arról írtam, amit a btrfs csinál, hogy block szinten checksumok párosítása (majd összehasonlítása), mert az nem igaz, hogy csak file alapú van.

Az, hogy mennyit számít, hát, imapnál nem fog sokat, hacsak nem a közös spamokat :D Backupnál lehet nagyon állat, ahol több gépről van backup, és egy csomó file közös. Persze ott elég is lenne a file szintű, de gondolom utólag könnyebb blokk szinten összehasonlítani, ha már úgyis van checksum minden blokkról... Nem?

https://btrfs.wiki.kernel.org/index.php/Deduplication

ezt még tanulmányoznom kell. Btrfs rulez

> Én arról írtam, amit a btrfs csinál, hogy block szinten checksumok párosítása (majd összehasonlítása), mert az nem igaz, hogy csak file alapú van.

Ja ertem.
Igazabol meg csak az van, mivelhogy 3.12-es kernellel szerintem meg nincs stabil disztribucio.

> Az, hogy mennyit számít, hát, imapnál nem fog sokat, hacsak nem a közös spamokat :D

Nekem errol mas a tapasztalatom.

> Backupnál lehet nagyon állat, ahol több gépről van backup, és egy csomó file közös

Ha az OS-t alkoto file-okrol beszelsz, akkor annak elenyeszo a mennyisege tobbnyire.

> Persze ott elég is lenne a file szintű, de gondolom utólag könnyebb blokk szinten összehasonlítani,

Kenyelmesebb, de sokba is kerul(het). Mindenesetre sokszor kifizetodo.

Jellemzoen jol johet meg VM-ek alatt. Tudok olyanrol, aki VM-ek alatt SSD-n hasznal ZFS-t+dedup-ot. Mivel az SSD draga, nagyon megeri meg igy is neki, mivel siman lekorozi sebessegben is ezzel egyutt is a sima HDD-kbol epitett rendszereket.
Megvan a maga kelye.

tompos

" Igazabol meg csak az van, mivelhogy 3.12-es kernellel szerintem meg nincs stabil disztribucio."

Az egy dolog. Utánaolvastam egyébként, nem tudom az opctl mit csinál pontosan, de a bedup továbbra is fileokat tud deduplikálni, nem blokkokat, ha jól értem, csak más módon. A spéci mount opció meg (amihez git es btrfs-progs kell, nem csak 3.12 kernel), az meg ha jól ovlastam azt csinálja, hogy az írás után késleltetve deduplikál, az viszont blokk szinten. Na ez a későbbiekben poén lesz egyébként, egyelőre ez még túl kísérleti ahhoz is, hogy itthon teszteljem. Ahol meg poén lenne, backup szerveren, ott a backupot kockáztatni húzós lenne :) De azért jó, hogy halad a dolog.

"Nekem errol mas a tapasztalatom."

Fura, ez azt jelenti, hogy a sok százezer fileban sok a közös blokk? Az hogy lehet? A levelek eltérnek, a fejlécben mindenképp, onnan meg kicsi az esélye, hogy egyezik valami elcsúszás nélkül. Nem?

"Ha az OS-t alkoto file-okrol beszelsz, akkor annak elenyeszo a mennyisege tobbnyire."

jogos. Sajnos egy csomó filet tudna deduplikálni, de a méretben igazából szinte nincs jelentősége. Egy root filerendszer mondjuk 1 giga adat nélkül, egy átlag wordpress oldal is több ennél, multimédiáról nem is beszélve. Akkor meg virtuális gépeknél, vagy azok backupjánál számíthat még sokat bizonyos felállásban.

"Kenyelmesebb, de sokba is kerul(het). Mindenesetre sokszor kifizetodo."

Mivel a btrfs blokkonként checksumot tárol, azt egy listába összegyűjteni, és az ismétlődést megkeresni nem annyira sok, és kész is a real time deduplikálás íráskor.

--

> bedup

Igen, en arra gondoltam. De jol reg volt, az adat konyvtaramra raengedtem poenbol es talalt vagy 2 file-t.

> Fura, ez azt jelenti, hogy a sok százezer fileban sok a közös blokk? Az hogy lehet? A levelek eltérnek, a fejlécben mindenképp, onnan meg kicsi az esélye, hogy egyezik valami elcsúszás nélkül. Nem?

Egyszeruen csak sok a kozos adat. Pl. az attachmentek mindenkepp, azok eleg sokat tudnak foglalni a tiszta levelekhez kepest. Aztan mindenfele korlevelek stb. Szoval azert van ott mit keresni.
De en nem mail szerveren, hanem annak a backupjan neztem, ami hardlinkekkel mukodik (dirvish). Szoval ha esetleg van a szerveren vmi olyan valtozas, ahol vmi valtozik a file-okon (pl. tulajdonos), akkor ott a dediplikacio segit, a hardlink nem.

> Mivel a btrfs blokkonként checksumot tárol, azt egy listába összegyűjteni, és az ismétlődést megkeresni nem annyira sok, és kész is a real time deduplikálás íráskor.

Nem tudom, h (fogja) csinalni a btrfs, zfs-sel csinaltam, es sokba kerul. Nyilvan akkor, ha van sok adat es plane, ha keves a memoria.
Sokan ugy tekintenek ra, vmi orokke experimental feature-re.

tompos

( ncc1701 | 2013. 12. 05., cs – 17:26 )

Zfs deduplikációhoz mennyi ram kell? Mitől függ, tárolt adat mennyiségtől/file számtól?

"minden 1TB adatra kell 12GB RAM"
erre te:
"Teljesen mas tapasztalatom van.
A gepben volt 8G RAM es kb. 5-6TB zpool, 2-3x dedupratio. Rajta dirvish, tehat sok kis file es sok metadata. Kb. ekorul fekudt meg. Miutan kapott meg ramot, mukodott."
majd
"Nem teljesen mind1?
8G volt az originalba es 128G-s gepbe raktam bele. Elobbre jutottal?"

Most én értek félre valamit?

A dedupratio alakulasa munin grafikonon:

http://rtfm.co.hu/zpool_dedupratio_munin.png

Sajnos a munin hujesege miatt mar nincs meg, hogy mekkora volt a dataset, de 5T-nal nagyobbra emlekszem.

A grafikonon jol latszik, hogy a vegen probaltam torolni, csokkent is a merete, de akkor mar nem tudtam rajta igazan segiteni. Azaz nem olyan, mint mondjuk ha a diszk megtelik akkor kopp es netovabb, hanem lenyegeben tultoltottem a rendszert, ami utan menthetetlen lett. Amennyire vissza tudok emlekezni, a pool sebesseget figyelembe veve ugy ~4T kornyeken kellett volna abbahagyni a tolteset (v. tobb ramot adni neki).

Konnyen lehet egyebkent, hogy teljesen rosszul emlekszem es joval nagyobb, akar duplaja volt az adatmennyiseg, kisebb viszont tuti nem.

tompos

Mar reg megvolt a zpool destroy:)
Nem emlekszem.

Meg erdekesseg, h zimbra es svn backupok alatt, vmint dump file-ok eseten (ahogy varhato volt) volt igazan utos.
Vmint probalgattam gzip --rsyncable-vel tomoritett dumpokat kesziteni, de ha jol emlekszem, az nem igazan sikerult (vagy rosszul emlekszem).

Ja es lz4 compression is be volt kapcsolva, kb. ~1.5-os ratioval segitett ra (megintcsak halvany emlek).

t

( dblaci | 2013. 12. 06., p – 14:29 )

Én btrfsen tárolom az imap levelezést raiden. Régóta, mondjuk min. 2 éve btrfs, vagy több, nem veszett még el adat. A sok file miatt, ha a ramban nem tudja cachelni, akkor kaparni fog rendesen nagyobb mailboxoknál, úgyhogy ssd javasolt, ez nálam is gondot okoz. A tömörítés miatt viszont kisebb, így kevseebb adatot kellbeolvasnia (a metaadat is tömörített elvileg)

# find . -type f | wc -l
542808
# du -s .
109677740

# df -h vmail
foglalt: 77242592
(ez csak a tömörítés miatt, miheztartás végett)

egyébként a find nagyon sokáig futott, kb. 20 percig... De ténylegesen a levelezés nem lassú imapon.

Ja és ez 516 fiók, és vegyes, van amelyik üres, van amelyik 5-10 giga. A 3tera levelezést speciel elképzelhetetlen soknak tartom, pláne 130 fiókhoz, de végülis miért ne.

( grandfather | 2014. 12. 25., cs – 13:04 )

Nekem a reiser4 jutott eszembe a sok kis fájlról, és az élő tömörítésről...

(Ismét) elérhető a mai kernelekhez is, és már rendelkezik discard funkcióval, viszont nincs vele semmi tapasztalatom.

Gyárilag csak a debian alapú elive-ban láttam támogatást rá. Ott azt igérik, h sokat dob a rendszer sebességén, nem mintha túl sok párhuzam lenne :)

http://en.wikipedia.org/wiki/Reiser4
http://sourceforge.net/projects/reiser4/reviews/?sort=created_date&star…