Dave Chinner előadás az XFS-sel kapcsolatos munkájáról

Fájlrendszer, NAS, storage

A Red Hat alkalmazásában álló Dave Chinner egy előadást tartott az XFS fájlrendszerről pár nappal ezelőtt a LCA 2012 rendezvényen. Amikor linuxos fájlrendszerekről esik szó manapság, akkor az ext3, ext4 mellett legtöbbet a btrfs-ről esik szó és kicsit feledésbe merültek a elmúlt évtized egyéb linuxos fájlrendszerei. Ilyen például a SGI háza tájáról eredő XFS is. Az XFS-nek előnyei mellett volt egy rendkívül nagy hátránya teljesítmény téren: retek lassú volt a metaadat módosítási műveletekben. Chinner előadásában arról beszél, hogy hogyan sikerült megoldania ezt a problémát (a "delayed logging"-gal) anélkül, hogy az XFS diszkformátuma megváltozott volna, illetve arról, hogy mi várható az XFS-sel kapcsolatban a jövőben.

( uid_18247 | 2012. 01. 21., szo – 17:38 )

(production környezetben) hol kerül elő leginkább a metadata modifying lassúsága? vagy pontosabban: milyen scenariok esetében jelent tényleges hátrányt?

(ha benne van a videóban, akkor meaculpa, még nem néztem meg)

Én pedig pont az ellenkezője miatt kezdtem xfs-t használni. Zoneminder minden egyes képkockát külön jpg fájlban tart, márpedig ez néhány kameránál is elég komoly fájl mennyiség egy hét alatt. Esemény törlésbe eddig minden fájlrendszer beletérdelt, minimum órákig tartott. Az xfs-nek is. De... Találtam egy blogot (ha érdekel megkeresem) ahol volt pár tuning paraméter. Nagyságrendeket nyertem időben a törlési sebességre. Egyéb felhasználásról nincs tapasztalatom, a többi helyen ext3-at használok.

Jajj, hat ezt ismerem, de francokat se segitett. Ill. helyesebben nemt udom, hogy milyen lenne anelkul, ahogy csianltam.

Ezzel mountolom:
/dev/sda3 /data/backup xfs delaylog,sunit=256,swidth=2560,logbufs=8,logbsize=256k,noatime,nodiratime 0 0

Az mkfs parancssort most nem talalom, de az is optimalizalva volt a raid levelhez es a HDD-k szamahoz.

Meg igy is lassunak talalom. persze aztan lehet, hogy bilibe log a kezem es a tobbi sem jobb:)

tompos

ui.: Mi ertelme van manapsag ext4 helyett ext3-mal osszehasonlitani? Annal persze gyorsabb akarhogyan is. Vmint miert nem ext4-et hasznalsz?

Nem biztos hogy minden adat pontos, régebben csináltam, de nagyságrendileg tényleg ilyen:

Adott a saját gépem, amiben egy darab sata vinyóra megy a rögzítés 4 kameráról folyamatosan 5-10FPS. Eközben helyet akarok csinálni, és mondjuk letörölném az elmúlt heti felvételt. Ez kb 15 millió fájl az események számától függően (ez akkor nem is tudatosult bennem, csak utána, azóta átparamétereztem spórolósabbra, most "csak" 4,5 millió fájl van egyszerre a winyón) és a hozzájuk tartozó db műveletek (ugye közben megy a rögzítés). Ez egy brutko random I/O, nem is csodálkoztam hogy lassú. De amikor majdnem reggel felkeltem és még nem nyertem vissza a szabad terület felét sem a winyón (7 óra alatt - ext3), akkor előbb leanyáztam a zonemindert és lelőttem. Rányomtam a könyvtárra egy "rm -rf"-et, hogy az majd gyorsabb. Tényleg az volt, majdnem fele idő alatt végzett a törlés másik felével.
Ekkor kezdtem fájlrendszert tuningolni. Nem nyert. Akkor megnéztem performancia összehasonlításokat, és az ext4 nyert. Csak nem nálam. A második az xfs volt, na ez sem jött be. Akkor találtam ezt a dokut, ezek után egy hét törlése néhány 10 perc lett. Lehet hogy az ext4-et is meg lehet tuningolni, gyári default-on elbukott, és mivel megoldást kerestem nem akadémiai összehasonlító munkát végeztem, így az első sikernél megálltam.

Az utóbbi volt az első gondolatom, amíg rá nem jöttem hogy a zoneminder függőségeinek híre hamva sincs solaris-on... Linuxon a zfs csak technológiai kísérlet, az ...bsd meg önmagában az :-)
Szóval kedvenc zfs fájlrendszerem alternatíváját kerestem (és nem a btrfs-t ami még kísérletnek is béta, bár a koncepció nagyon jó).

Plusz jelenleg rolling delete van ami helytakarékosabb. Azaz stabil 95%-on tartja a zoneminder a foglaltságot úgy, hogy mindig a legrégebbi nem archivált felvételt törli.

( tompos v | 2012. 01. 21., szo – 17:39 )

Nekem a delaylog-gal is lassu:)

tompos

( wladek1 | 2012. 01. 21., szo – 19:52 )

A "lassu" és az "XFS" egy lapon nekem eddig sosem tünt fel...
Bár...gyakran módosuló kis fájlok esetében valóban nem ok, de a legfőbb hátránya az, hogy gyors kiszolgálásra alkalmas, csak "fsck" -t (xfs_check) ne kelljen rajta futtatni...

If the filesystem is very large (has many files) then xfs_check might run out of memory. In this case the message out of memory is printed.

Egen, egyebkent eloszeretettel hasznalok XFS -t, az egyik, ha nem a legjobb fs; sebessegben pedig semmi meg sem kozeliti (szerintem) - azonban ez a bug/feature nagyon idegesito; igy kizarolag volatile adatoknal/nagy fajlok eseten hasznalom; ott ez a bug nem jon elo. Minden mas esetre ext4/reiser/jfs.

Hasznos volt az idezett thread, koszi; ennyire eddig nem merultem bele...

( joco01 v | 2012. 01. 21., szo – 20:22 )

Az életben nem használtam XFS-t, de nagyon szépen beszél, nagyon érdekes dolgokról, és létszik, hogy nagyon ért is hozzá. Az XFS-től elvonatkoztatva is megtudtam, hol áll a fájlrendszerek technológiája, jó látni, hogy milyen nagy a fejlődés ezen a téren.

--
joco voltam szevasz

( necrolite | 2012. 01. 21., szo – 22:03 )

Jol latszik hogy inkabb mast eroltetnenek mint az oracle szellemi tulajdona ;o) inkabb a sajat foztjuket eszik ;oP Regen is kedveltem az xfs-t de most ujra elo fogom venni.

( lavian v | 2012. 01. 21., szo – 22:07 )

Szép, amit mond és használom is az XFS régóta, de a végén az SSD-s benyögése mindent vitt nálam. :)
Lassan a postaládába is építenek egyet, erre: Nincs rá szükségünk.
Értem én, hogy a hagyományos lemezekből lehet hatalmas kapacitást olcsón összerakni, de csak évek kérdése és nem így lesz.

( Benjamin v | 2012. 01. 23., h – 13:56 )

subscribe

-----
“Firefox, you say? No I don't play Pokémon”