Fórumok
Nézelődnék levelezőszerver fronton. Kevés tárhely lenne sok felhasználónak. Most levelezőrendszertől függetlenül, maildir formátumban tárolt leveleket érdemes-e BTRFS köteten tartani és éjszakánként tolni rajta egy "offline" deduplikációt? Ha jól értelmeztem, a kötet ilyenkor is elérhető, és ha szintén jól értettem, elvileg minden működhet tovább ezen művelet közben is, ami írna/olvasna az érintett területen, ugyanakkor kevésbé erőforrás/memóriaigényes mint egy online deduplikáció. Mennyire működhet ez valójában és mennyire lehet megbízható? Egyáltalán jó irányba tapogatózok?
Hozzászólások
A BTRFS még nem production ready, éppen ezért én nem tennék rá mailboxokat. Esetleg valaki nyilatkozhatna arról, használ-e ZFS on linuxot hasonló célra?
Még mindig nem? Már mióta fejlesztik pedig.
ZFS tud valami memóriaspórolósabb blokk szintű deduplikációt?
Mikor utoljára FreeNAS alatt használtam, próbáltam, eléggé lezabálta a memóriát.
Elvileg egy ideje már "production ready" a készítők szerint és ezen cégek szerint is.
Szerintem a no longer unstable != production ready.
"Szerintem a no longer unstable != production ready."
Itt két dolog van összemosva. Az egyik a "disk format" állandósága, a másik meg a fájlrendszer stabilitása (mennyi hibát vét, mennyire száll el, ...).
A Linux kernel API-ja még mindig nem stabil (unstable), + "fast development speed", mégsem lehet rá mondani, hogy ne lenne production ready.
Mindenkinek magának kell eldöntenie, hogy miben mennyire bízik meg (nyilván egy csomó vélemény + saját tesztek alapján).
Először érdemes lehet nem kritikus dolgokra rakni, majd kedvező tapasztalatok után kritikusakra is.
Amint itt is látható, a vélemények nagyon megoszlanak.
AFAIK az definicio szerint sosem lesz stabil.
Azért ettől a "testing in production" és hasonlóaktól nem esem hasra. :) Amíg valamelyik komolyabb disztró nem teszi meg default fs-nek és nem lesz komolyabb user bázis ami legalább fél éve nyúzza tényleg élesben (desktopból a nagyszerverig, áramszünetekkel és mindennel tarkítva), addig azért vannak fenntartásaim.
Említettétek a tömörítést. Lehet egyszerre használni a deduplikációval BTRFS alatt? Erre nem találtam választ egyértelmű, gondolom, próba-cseresznye :D
Nincs valami teszt a BTRFS - ZFS erőforrásigényéről?
Lehet.
Mint lentebb írtam, van egy vmware számára NFS-en kipublikált tárolóm, ami deduplikál és tömörít is egyben.
3x250 GB SSD van benne, stripe módban és 8 GB memóriát vesz le a deduplikáció a 16-ból.
Utólag bele lett téve egy 6 TB-s HDD is, amire éjjel készül egy backup, az is deduplikálva és tömörítve. Ez a memóriahsználaton már nem változtatott, továbbra is 9 GB körül mozog az összmemóriahasználat.
A szerver egy HP Proliant ML310e, i3-4130-as procival. Amikor másoltam a gépre amennyi belefért a bondolt 2x1 Gbps hálókártyába, akkor a proci megérezte, kb 50% körül volt terhelve, de semmi extra.
Ez az i3-as felállás csak az előtesztje egy komolyabb szervernek, amiben már xeon lesz, de nem kizárt, hogy ez a proci is bírná az iramot.
Végkövetkeztetés: ZFS-hez ha deduplikálsz is, legalább 16 GB memóriád legyen, szerintem az ECC is alap kell legyen, és valami tűrhető proci.
Elvileg a prociigény csak tömörítéshez nem kellene különbözzön BTRFS és ZFS között, mivel az algoritmus ugyanaz, a többi pedig nem különbözhet jelentősen.
Én BTRFS-t backupnak használok, a tömörítés és a snapshot miatt, de nincsenek adataim a teljesítményigényről.
Annyit tudok, hogy kb 50 GB új adatot ment le hétvégén a szerver, és két procimaggal (Intel(R) Xeon(R) X5650 @ 2.67GHz) a gép simán elbírja a terhelést. Így, hogy csak tömörítés van, a memóriaigény gyakorlatilag tart a nullához.
Egy másik szintén backup szerver pedig 1 maggal is bírja (Pentium(R) CPU G2020T @ 2.50GHz), igaz ott kevesebb az adatkülönbség.
SLES-ben majdnem egy éve default fs.
Ezt nem tudtam. A slesnek mekkora az erdemi olyan juzer bazisa aki nem valt mondjuk meg mindig panikszeruen ext3-ra installkor mikozben az ext2-ert hullat nehany konnycseppet?
úgy érted ext4-re? nem tudom.
mi pl maradtunk ext4-en, mert a storage dedupol úgyis.
Ilyen alapon pl. a zfs sosem lesz használható állapotban linuxon, mert a licence miatt sosem kerülhet egy lemezre a linux disztró meg a zfs.
Elofordulhat. :) A zfs -hez van olyan disztro vagy opcio ami ad supportot, raadasul elerheto mas os-eken.
Amint lesz sajat btrfs fejlesztom, en is elgondolkozom rajta:)
KOmolyra forditva, a sajat tapasztalatombol irok. Hasznalok btrfs-t productionben, csak nem adat alatt. Az OS-t arra szoktam pakolni, meg a laptopomon is az van.
Én három éve használom a céges laptopomon és két éve megy a fő szerverünkön is (utóbbin RAID 1-ként).
Tegnap btrfseztem meg olvasgattam rola mindenfelet es hat nekem vegyes a kep. Tobbszor latni, hogy elindul egy feature aztan jajj hopp megsem es ne hasznald mert ki tudja mi mesz. Gondolok itt peldul az ext4 konverziora es egy kicsit az online deduplikaciora. A tomoritesi opciok is erdekesek, illetve hogy lz4 meg nincs, de majd lesz. Perpill nem erzem az ext4-nel atutoen tobbnek az alapfeature-oket, bar pont a tomorites miatt kezdtem nezegetni webszerver es mailszerver ala.
"Perpill nem erzem az ext4-nel atutoen tobbnek az alapfeature-oket"
Pedig van egy pár, amelyek önmagukban is elég ütősek:
(File Striping, File Mirroring, File Striping+Mirroring, Striping with Single and Dual Parity implementations)
Hogyne, de még ilyenek előfordulnak:
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 "Warning: As of 4.0 kernels this feature is not much used or well tested anymore, and there have been some reports that the conversion doesn't work reliably. Feel free to try it out, but make sure you have backups."
Ezt a feature-t már nagyon régóta tudja (elsők között támogatta) és a 4.0-ás kernelig elég megbízhatóan is működik.
Nem tudom a 4.0-ba mit sikerült beletenni (btrfs, ext3/4 vagy más kernel módosítás?), ami ezt a feature-t lerontotta.
Megcsinálhatnák Ext4-be a tömörítést. Más nem kellene nekem. ;)
A kissé eltérő mail headerek betesznek a dedupnak. Persze ez függ a levelező rendszertől is, de tipikus probléma amennyire tudom.
Kevés tárhely lenne sok felhasználónak. [...]
egy masik megoldasa lehet a problemanak, ha nem a maildir-eket akarod deduplikalni, hanem a leveleket atkuldod egy email archivalonak, ami tomoriti es 1 peldanyban tarolja a leveleket, mellekleteket. A mail szerverrol pedig siman torlod az x nap/honap/ev/...-nel regebbi leveleket. Persze ehhez kell egy kulon (virtualis) gep az email archivumnak...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
BTRFS-t en nem hasznalnek priductionben
ZFS OK, de azzal meg dedup-ot nem hasznalnek. Nem mintha nem mukodne, csak nem eri meg, olcsobb a HDD.
Cserebe viszont performance ddegradaciot kapsz rendesen (memoriazabalas + nagymerteku fragmentacio). Vannak kisebb-nagyobb egyeb gebaszok is, ami miatt valojaban csak nagyon-nagyon specialis esetekben eri meg.
A BTRFS lényegi részei már stabilak, de az fsck rész nem tökéletes hozzá, tehát ha fájlrendszerhibába ütközöl, akkor lehet nem megy instant a javítása.
Ezt figyelembe véve döntsd el, hogy használod-e.
Én deduplikációt ZFS-el használok linux alatt, egy esxi klaszternek kiajánlott tárolónál, BTRFS-en nem próbáltam. ZFS-né az biztos, hogy +8-16 GB memóriát kell tegyél a szerverbe ahhoz, hogy működjön a deduplikáció.
Amint viszont ajánlanék a deduplikáció helyett/mellett az a tömörítést. Úgy a BTRFS mint a ZFS tud tömöríteni, amivel én több helyet spórolok mint a deduplikációval.
Annak ellenére, hogy az említett tárolón teszterek egy rakás windows-t klónoznak egymásról (több verzió és architektúra van, nem csak egy alap) deduplikációval 1,24x-es megtakarítást érek el, míg tömörítéssel 1,59x-et.
Leveleknél, főleg úgy, hogy a header tényleg jó eséllyel bekavar a tömörítés eredményes lehet.
+1 a tömörítésre
Én a mérés híve vagyok:
- fogd meg a mailboxokat
- másold át egy asztali PC-n kialakított BTRFS partíciójára
- itt dedup
- az arányt légyszíves oszd meg velünk
Másik teszt:
- Üres BTRFS partíciót csatold fel compress-force=zlib opcióval és másold fel a mailboxokat.
- arányra szintén kíváncsiak vagyunk
- majd erre is dedup - ez esetben mennyit segített? Elvileg sokkal kevesebbet.
A btrfs-t mellesleg compress-force=zlib miatt szeretem laptopon vendég Linuxokra. Tavaly 8 GB-nyi adattal rendelkező backup szerver másolaton 1/3 helyet megtakarított vegyes állományoknál, a deduplikáció viszont elhasalt a kísérletemben. Végül a btrfsck még nem tökéletes működése miatt backup szerveren nem tértem át.
Én is a mérés híve vagyok, de nem szeretek én magam mérni :D.
Saját mérés nélkül elég nehéz lesz...
de mivel engem is érdekel a téma, egy valamit lemértem. Vettem egy kb 60 GB-s maildirekkel teli mappát és átmásoltam egy zfs pool-ban.
A compress értéke 1.08x lett.
Mivel nincs ötletem, hogy lehet, ha lehet egyáltalán egy storage pool-on belüli fájlrendszerben megnézi a dedup adatokat, ezért arra nem tudok infót mondani.
Annyit meg tudok állapítani. hogy 1.35-ről (másolás közben mértem, kb 60-70%-nál) 1.34-re csökkent a dedup hatékonysága, de mások is dolgoztak a szerveren.
A két zdb lekérés:
794G completed (27756MB/s) estimated time remaining: 176057hr 20min 56sec
No leaks (block sum matches space maps exactly)
bp count: 8380462
bp logical: 1041567599104 avg: 124285
bp physical: 855219038208 avg: 102049 compression: 1.22
bp allocated: 857063646208 avg: 102269 compression: 1.22
bp deduped: 299073280512 ref>1: 374182 deduplication: 1.35
SPA allocated: 557990365696 used: 78.03%
additional, non-pointer bps of type 0: 2191
817G completed (29536MB/s) estimated time remaining: 165444hr 57min 02sec
No leaks (block sum matches space maps exactly)
bp count: 8626473
bp logical: 1066946071552 avg: 123682
bp physical: 880430176768 avg: 102061 compression: 1.21
bp allocated: 882339830784 avg: 102282 compression: 1.21
bp deduped: 302722580480 ref>1: 413304 deduplication: 1.34
SPA allocated: 579617250304 used: 81.05%
additional, non-pointer bps of type 0: 2791
Ha azt feltételezzük, hogy mások semmi jelentőset nem csináltak közben, illeve ebben az esetben a compress ki volt erre a fájlrendszerre kapcsolva, akkor épp ki tudsz belőle számolni hasznos adatot.
A deduplikációt mekkora blokk mérettel használod?
Default.
De ha megírod, hogy kell megnézni, akkor pontosan megnézem.