BTRFS + éjszakai dedup maildirhez

UNIX haladó

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?

  • 3003 megtekintés

( Szenti v | 2015. 09. 23., sze – 12:47 )

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?

The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels.
The Btrfs code base is under heavy development. Every effort is being made to keep it stable and fast. Due to the fast development speed, the state of development of the filesystem improves noticeably with every new Linux version, so it's recommended to run the most modern kernel possible.
For benchmarks, it's recommended to test the latest stable Linux version, and not any older. If possible, it's also recommendable to test the latest Linux development version. Also, it's recommended to test the different options, f.e. different compression options.
Newly added features may need a few releases to stabilize.
If you have any bug, problems, performance issues or questions while using Btrfs, please email the Btrfs mailing list (no subscription required). Please report bugs also on Bugzilla.

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.

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.

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.

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:

  • Writable snapshots, read-only snapshots
  • Subvolumes (separate internal filesystem roots)
  • Compression (zlib and LZO)
  • Integrated multiple device support

    (File Striping, File Mirroring, File Striping+Mirroring, Striping with Single and Dual Parity implementations)

  • SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for reuse) and optimizations (e.g. avoiding unnecessary seek optimizations, sending writes in clusters, even if they are from unrelated files. This results in larger write operations and faster write throughput)
  • Efficient Incremental Backup
  • Background scrub process for finding and fixing errors on files with redundant copies
  • Online filesystem defragmentation
  • In-place conversion of existing ext3/4 file systems
  • Seed devices. Create a (readonly) filesystem that acts as a template to seed other Btrfs filesystems. The original filesystem and devices are included as a readonly starting point for the new filesystem. Using copy on write, all modifications are stored on different devices; the original is unchanged.
  • Subvolume-aware quota support
  • Send/receive of subvolume changes
  • Efficient incremental filesystem mirroring
  • Batch, or out-of-band deduplication (happens after writes, not during)

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."

( dap | 2015. 09. 23., sze – 13:22 )

A kissé eltérő mail headerek betesznek a dedupnak. Persze ez függ a levelező rendszertől is, de tipikus probléma amennyire tudom.

( sj | 2015. 09. 23., sze – 13:36 )

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)

( tompos v | 2015. 09. 23., sze – 14:06 )

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.

( akoscomp | 2015. 09. 23., sze – 14:45 )

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.

( uid_6201 v | 2015. 09. 25., p – 10:04 )

É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.

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.