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

 ( trey | 2012. január 21., szombat - 18:23 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

(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)

"Metadata operations in XFS have historically been slower than with other file systems, yielding poor performance with operations such as mass deletions of large numbers of files."

--
trey @ gépház

azaz? poresz törlése seed szerveren?

azaz: report output könytár takarítása (pl)

annál kevésbé érdekes, mert ott nagy fileok vannak, ellenben banki témában GIRO fileok esetén nem biztos, hogy mindegy

Pl. backuppc v. dirvish szerveren, mailder jellegu konyvtarakat hasznalno mail szervereken, FS cache-t hasznalo webszervereknel.
Szoval ugy altalaban, ahol sok kicsi file-lal kell bajlodni es azok sokat is valtoznak.

tompos

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

Azt hiszem, mindannyiunkat erdekelne:)

tompos

+1

íme, ebből dolgoztam:
http://www.everything2.com/index.pl?node_id=1479435

A legszebb a konklúzió a végén:
"delete performance has actually superseded that of ext3, for both random and sequential deletes! The most major weakness of XFS has been eliminated"

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.

Legutoljara kb. egy eve mertem, akkor az ext4 es az xfs kb. hasonloan teljesitett, lenyegeben fej-fej mellett voltak.

Mindenesetre ha ez a helyzet en lehet elgondolkoznek az mkfs-en az rm helyebe. Bar igy, hogy lement rovid idore, mar valoszinuleg nem szamit.

tompos

az mkfs-t szkripteljem bele a zoneminderbe hogy ha fogy a helye akkor ne csak a régi felvételektől szabaduljon meg hanem mindentől? :-)

Nem, hetente kulon particiora rakni. Vagy epp zfs-sel is lehet okositani.

tompos

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.

Nekem a delaylog-gal is lassu:)

tompos

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

Idézet:
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.

Idezet honnan? Valoban volt ilyen bug, amit aztan javitottak.
Szoval erdekelne, miert pont ezt idezted be?

tompos

man xfs_check szerint ez jelenleg igy van (DIAGNOSTICS szekcio), illetve tapasztaltam is.
8 Gb ramot siman megevett; + 64 G swap -ig kellett elmenni egy nyavajas check miatt.
Ha ezt javitottak, akkor viszont most en kerek idezetet.

http://groups.google.com/group/hun.lists.mlf.linux-flame/browse_thread/thread/462366a9c84aa0fd/c6fcbd83ced91d08?#c6fcbd83ced91d08

Igazad van, en emlekeztem rosszul, nem javitjak es nem is fogjak, ha jol gondolom.

Viszont a lenyeg, h az fsck-val nem egyenerteku az xfs_check. Az a comment egy kicsit felrevezeto.

tompos

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

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

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.

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.

Szerintem inkább arra gondolt, hogy az XFS alapból elég gyors lesz SSD-n is.

--
joco voltam szevasz

Lehet, de nekem a gyors válaszokból, inkább a lerázás jött le.

subscribe

subscribe

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