Milyen naplózó filerendszert tegyek Linux alá?

Fájlrendszer, NAS, storage

A napokban vetődött fel az a kérdés a Fórumban, hogy vajon milyen naplózó filerendszert kellene telepíteni manapság egy Linux disztó alá, hogy a legnagyobb teljesítményt és biztonságot érhessük el.

Mintha Justin Piszcz meghallotta volna a kérdést, mert azonnal össze is ütött egy FS benchmark versenyt a népszerű linuxos journaling filerendszerek között. A versenyben az alábbi FS-ek szerepeltek: ext2 (mint kakukktojás), ext3, reiserfs, jfs, xfs. Lássuk mit állapított meg a teszter (huh, de sok ilyen tesztet láttunk már...).A teszt során használt konfiguráció:

Számítógép: Dell Optiplex GX1

CPU: Pentium III 500MHZ

RAM: 768MB

SWAP: 1536MB

Controller: Promise ATA/100 TX - BIOS 14 - IN PCI SLOT #1

Merevlemezek:

1] Western Digital 250GB ATA/100 8MB CACHE 7200RPM

2] Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM

Tesztelt merevlemez: The Western Digital 250GB

A tesztek 2.4.26-os Linux kernel alatt futottak, 2.3.2 libc verzióval.

A teszt az alábbiakból állt:

- 10.000 file létrehozása ``touch''-csal

- ``find'' futtatása a könyvtárban

- könyvtár törlése

- 10.000 könyvtár készítése ``mkdir''-rel

- ``find'' futtatása a könyvtárban

- a 10.000 könyvtárat tartalmazókönyvtár törlése

- kernel tarball másolása egyik diszkről a tesztelt diszkre

- stb.

A konklúzió szerint ha valaki naplózó FS-t szeretne, akkor a következőkből célszerű választania (a tesztjei alapján): JFS, ReiserFS vagy XFS. A cikk írója meglepődött az ext3 lassúságán, hiszen - mint, írja - ez az alapértelmezett FS számos disztribúcióban.

A tesztet megtekintheted itt.

( drastik | 2004. 05. 11., k – 10:38 )

itt most az a kerdes hogy a lassusag vagy a megbizhatosag szamit egy naplozott filerendszernel.

( ishida | 2004. 05. 11., k – 10:49 )

Annyi ilyen benchmarkot láttam már, különböző eredményekkel. Elolvastam, elgondolkodtam rajtuk, azután Reiserfs-t használtam továbbra is, mert jobban tetszett a neve.

:)

Ez olyan mint az a bizonyos titkárnő választás: egyik 3 nyelven beszél, a másik nagyon jól tud gyors- és gépírni, de én azt választottam, amelyiknek a legnagyobb a c s ö c s e. :)

( Vudumen | 2004. 05. 11., k – 10:54 )

Szokas szerint kihoztak az ext3at a leglassabbnak de nemtudom pl a dir_index opciot bekapcsoltak-e. Ha woodyval csinaltak akkor tuti nem leven az alapbol abbanlevo tune2fs nem is tudja ezt. Backportoltat szoktam hozza hasznalni.

Amikor sok elem van 1 konyvtarban (pl 10000 file) akkor nagyon-nagyon-nagyon sokat gyorsit rajta...

( tomyellow | 2004. 05. 11., k – 10:58 )

Benchmark-ok.

Azok olyanok, mint a közvéleménykutatás. Néhányan jól megélnek belőle, akinek éppen kedvez, az örömködik, de amúgy nem jelent semmit.

IMHO

1. 10000 file létrehozása touch-csal. Irreális. 200 10-500 kB-s file létrehozása értelmesebb teszt lett volna.

2. find futtatása egy könyvtárban. Irreális. 5 szint mélységű könyvtárhierarchiában, ahol minden könyvtár tartalmaz 50-100 elemet (file-okat, könyvtárakat vegyesen), akkor az reálisabb.

3. UA. 1. pont

4. AU. 2. pont

5. Na, ennek van értelme, de nem egy szálon. Alapvetően nem az érdekel, hogy mennyi idő alatt másol át egy file-t, hanem az, hogy közben mit tudok (ill. a többi felhasználó mit tud) kezdeni a rendszerrel.

Üdv.: Tomyellow

( antiemes | 2004. 05. 11., k – 11:23 )

Hi!

Szerintem erdemes lett volna beletenni a benchmarkba azt, hogy egy nagy (mondjuk 700MByte-os vagy 2GByte-os) file-t mennyi ido alatt tud torolni. Ugyanis ez nalam eleg lassu.

By(t)e

TBS::Antiemes

( egmont | 2004. 05. 11., k – 11:50 )

Én eddig ext3-at és reisert használtam kábé fele-fele. Nem tudom, melyik a gyorsabb. De elszállás során az adatokat valami eszeveszettül össze-vissza kuszálni még csak a reiserfst láttam :)

Hát sajna énis hasonlót tapasztaltam.

Hevenyészett tesztem lényege két particion ext3/resierfs paralell futtattam egy sok sok file műveletet végző bash scriptet (időbélyegzőt is beszurt a fileba) es kihuztam alola az áramot szépen.

Az eredmény az volt (számomra) hogy reiserfs valóban gyorsabb de a tesztelt verzio (nema legujabb 3-as aszem) csak igazán hangyányival.

DE DE DE DE

resierfs a tesztek 80% ánál a file végéhez vlmi egész más adatokat fűzött ugymond javításként (előző teszt file végének tűnt)mig ext3 egyszersem.

Szerintem:

1. biztonság

2. gyorsaság

Es hiába gyors ha....

( vajtsz | 2004. 05. 11., k – 12:16 )

Csak én hiányolom a tesztből a nem tervszerű leállást ???

Nem azért jó a naplózó file rendszer hogy "terven kívüli" leállásnál is "jó" marad a filerendszer ?

Valo igaz, hogy regebben voltak gondok a ReiserFS-sel. Viszont lassan 3 eve minden desktop es mobil gepemen ReiserFS fut 2.6-os kernellel. Szamtalanszor van olyan, hogy elfelejtem bedugni a halozatba a notebookot, es csak azt veszem eszre, hogy kikapcsolt. Ennek ellenere a ReiserFS ez alatt a ket ev alatt meg nem okozott nekem kellemetlen meglepetest. A gyorsasagahoz ketseg sem ferhet, egyetlen dolgot szoktak meg felhozni ellene, a CPU overhead-je. Valoban nem jo valasztas a ReiserFS egy Pentium II 300-ra, de en PIII 700-as processzorral evekig hajtottam, es teljesen jol mukodott.

Egyetlen dologra kenyes a ReiserFS. A memoriara. Ha a memoriad rossz, vagy hibazik, akkor osszekuszalhatja az FS-t, es csak a ``reiserfsck --rebuild-tree'' rakja rendbe. Volt egy gepem, ahol ReiserFS vagy kernel bugra gyanakodtam mert ket hetenkent osszeesett a filerendszer es fsck-zni kellett. Aztan irtam a Namesys-es gyerekeknek (a ReiserFS fejlesztoi) akik azonnal irtak vissza a bugreport alapjan, hogy csereljek memoriat (egyebkent a gep jol mukodott a memoriaval, egyszer-ketszer volt egy honapban titokzatos sig11, de azt program hibanak tulajdonitottam). Kicsereltem a memoriat (ennek masfel eve) es lass csodat, azota tokeletesen mukodik a gep. Szoval ha FS hibad van, az nem biztos, hogy csak az FS hibaja lehet.

A ReiserFS (v3) egy nagyon _altalanos celu_ filerendszer. Ha mondjuk ACL-ek kellenek, akkor valoszinuleg nem zet valasztanam (bar vannak patchek hozza). De nekem eddig amire hasznaltam, arra tokeletes volt.

( _Joel | 2004. 05. 11., k – 13:57 )

Ki volt kapcsolva vajon az IDE drive cache?

>Egy geek vagy 120 vagy 50 kg.

Hat valahol a ketto kozott vok. :-)

Nem hasznalok quotat, es ennek az oka az, hogy a felhasznalo kinovi, es kell neki hely. Mikor kell a hely? Amikor a vilag masik vegen vagyok, es persze azonnal. Es a felhasznalo mindig erosebb, mert ha kell akkor befenyit a fonokevel, ami sok esetben a te fonokod is. Igy kenytelen vagy megcsinalni. Helyette jobb ha egy szkript szepen kigyujti a felhasznalok helyfoglalasat, ami he tullep egy hatart akkor jelez. Mondjuk levelben. Ha ez tartos, akkor szolok neki. Ha nincs reakcio akkor mit tesz isten nem fog a filejaihoz hozzaferni :-O

Nefelj megtanulja, hogy nem lepi tul a hatart :-)

Ez mar sokszor tesztelt, es jol bevalt modszer.

Persze nem mindig teheto meg ez, olyankor marad a quota. Viszont akkor mas filerendszerrel.

Haaat volt mar ilyesmi. Eleg egy kis sz#rul megirt ciklusa (neverending story :) ) majd lottek a tarhelyenek.

Volt is nyafogas, meg fonokkel valo fenyites. A fonokot siman lehutottem azzal, hogy vagy igy, vagy vegyen egy (akkoriban) majd felmillas HDD-t. Ezekutan meg jol leqrta a felhasznalot :) Olyan jo volt hallani. /me EVIL

Annyit a quota vedelmeben, hogy azt is be lehet allitani, hogy szoljon.

( ssikiss | 2004. 05. 12., sze – 09:06 )

Több mint 2 éve használok gond nélkül egy fájlszervernek is használt gépen reiserfs-t úgy, hogy az egyéb nagyfogyasztású villamos eszközök bármikor levághatják a biztosítékot, és teszik is átlagban hetente egyszer-kétszer.


Quota patch van, bár általában 1-2 verzóval lemaradva az aktuális kerneltől, és nemsokára jön a Reiserfs4 is, ami gyorsabb lesz, mint a mostani. :)

( sygma | 2004. 05. 12., sze – 10:11 )

A 2.4.26-ban bugos az XFS (fsync () hatástalan), úgyhogy az írási eredmények hamisak. 2.4.27-pre2 -ben javítva van.

-Sygma