fs optimalizálás sok fájlhoz

Naplózó filerendszerek (journaling)

Hi!

Van egy nagy (500GB) partíción, amin van elég sok (~10M) kicsi fájl. Méretileg ezek 2 kategóriába sorolhatóak (200-400byte, szóva <512, és 60k-100k). Most egy ext3- on csücsülnek, s az érdekelne, hogy ezt hogyan lehet/ érdemes optimalizálni. A fontos szempont, hogy gyorsan olvasható legyen, ha nem annyira helygazdaságosan tárol az nem érdekes, az írási sebességnek sem kell extra gyorsnak lennie, a legfontosabb szempont az olvasás. Esetleg megoldható lenne, hogy másik fs- t rakjak alá, ha az annyival jobban kezel ennyi fájlt. Ezenkívül van pár ezer nagyobb fájlocska (~20- 60MB).

Köszi a válaszokat, ötleteket, becnkmarkokat. Néhányat ugyan már olvastam, de azokból nem lettem sokkal okosabb.

( lacika v | 2007. 10. 29., h – 06:16 )

Ha az ext3 -nal maradsz, akkor javaslom:
#mkfs.ext3 -b 1024 -O dir_index -O journal_dev /dev/sdb1
Jol tud jonni mind a kis blokk méret, mint a directory index sok pici file eseten. Ha van lehetoseged, akkor a journalt rakd masik merevlemezre, ez is javithat a performancian (foleg ha kulon kontrolleren figyel a masik disk).
Egyebkent milyen fs -ek kozul valogathatsz?
Meg nezd meg ezt, van ott valami benchmark tool is.
Ezt is ajanlom figyelmedbe.

--
http://laszlo.co.hu/

hm.. tipikusan nem segit ekkora file méret esetén a kis blokk méret(szerintem)
Amivel lehet sporolni:
megkéred a rendszert hogy ne foglalkozzon az fileok atime -jával. (fstabban: noatime opcio)
Nem tudom milyen kritikus adatok vannak a winyon, de érdemes lehet játszani a writeback el.
+1 dir_index
+1 journal atrakasa sem hangzik rosszul

http://www.nabble.com/RFC:-Tuning-ext3-t3774153.html

Igazad lehet a blokk méretnél. Viszont azt is figyelembe kell venni, hogy szekvenciálisan érjük el az adatokat, vagy random. Mert ha random és túl nagy a blokk méret, akkor nem hogy javulást érünk el, hanem romlani fog a teljesítmény. Szerintem jelen esetben nem szekvenciális adatelérésről beszélünk, hanem véletlenszerűről (a téma indítója megírhatná nekünk) és ilyenkor jobb teljesítmény/tárhely eredményt kapunk, mint "túlméretezett" blokkok esetén, nem? Write_back -el meg próbálkoznék én sem, ha kritikus az adat.
--
http://laszlo.co.hu/

Bármikor bármelyik kis fájlra lehet hivatkozás, szóval random elérésről van szó, és elég gyakran, emiatt kell a gyors olvasás. Ezt a write backet fejtsétek ki légyszi, ha lehetne. Ha egy hardreset szerű leállásnál (tfh évente max. 2) elveszik 4- 5 ilyen kis fájl, az még nem gond, ha ennél több, akkor igen.

hm, ezt elfelejtettem leírni, hogy nincsenek kifejezetten nagy könyvtárak. Ahol a sok fájl van, 5 szintes hierarchia uralkodik, szintenként 0..9 könyvtárnevekkel, szóval szintenként 10 darab node, és a levelek (fájlok) száma általában <32. Néhol van pár száz, de az ritka. Ebben az esetben is van értelme a dir indexnek? Azt hiszem, hogy jövő héten komoly tesztelésnek kell alávetnem... .

Megoldható ez valahogy a már meglévő fájlrendszeren, vagy mindenképpen újra kell formázni? Egy debian linuxról van szó, szóval azon fájlrendszerek közül válogathatok, amiket a 2.6.21- es forgatott kernelem támogat, de nyílván újra tudom forgatni. Journalingot hogy lehet másik lemezre rakni? Mekkora lemez kell neki 500GB- s partíció esetén. Mi van akkor, ha ez a journalingos lemez elfüstöl??

Ha journal nem elerheto, akkor az fs read-only lesz, persze ha minden osszejon akkor file serules is lehetseges, de erre nincs nagyon sok esely ha mint irtad nem nagyon van sok iras.
Atrakni meg lacika jol leirta -O journal_device

Kis file-ok sebessegere meg az xfs es a raiserfs szokta verni a mellet.

"Kis file-ok sebessegere meg az xfs es a raiserfs szokta verni a mellet."

halihóóóó, álljon meg a menet, te kicsit el vagy tévedve ... az XFS az éppen, hogy nem jó kis fileokhoz...

nézz körbe ebben


és itt van egy "széles" körű fs benchmark

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.10-pancs1-wifi2 - 2.6.22.9 kernel madwifivel itt

( Jason v | 2007. 10. 29., h – 10:38 )

noatime, dir_index, s mkfs-nél news típust megadni, így sok pici filera saccol.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( zwei | 2007. 10. 29., h – 10:40 )

Elgondolkodnék az adatok több és gyorsabb diszkre való szétterítésén. (stripe)
Már az is dobhat valamit az olvasási teljesítményen, ha simán csak tükrözöd a diszket. (Ha jól tudom tükrözött diszknél az olvasás round-robin megy a két diszk között.)

( pinyo_villany | 2007. 10. 29., h – 13:04 )

reiserfs találták ki tipikusan kis fileokhoz
XFS-sel ne is próbálkozz, mert az nagy méretű file-kohoz találták ki és megőszűlsz amíg egy rakat kis file-t törölsz .. (amugy én ezt használom)
reiser4 tömörítéssel, gyors és kis file-okhoz is optimális, de nincs benne a vanilla kernelben

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.10-pancs1-wifi2 - 2.6.22.9 kernel madwifivel itt