Az ext3 filerendszer teljesítményének növelése a journal flash diszkre helyezésével

Fájlrendszer, NAS, storage

A blogbejegyzés írója hardveres RAID6 + LVM megoldást alkalmazva arra jutott, hogy az egyik filerendszeren folyó komolyabb IO aktivitás kihatással van az összes többi teljesítményére. Ha az egyik filerendszeren írási művelet - például a metaadatok frissítése - folyik, akkor a többi filerendszer teljesítménye extrém módon csökken (az olvasási teljesítmény a padlón, a válaszidő megnövekszik, stb.).
A probléma megkerülésére próbálkoztak már sok minden - különböző mount opciók, IO ütemezők, /proc/sys/vm beállítások, stb. - alkalmazásával, kevés eredménnyel.

Azonban az SSD-k felbukkanása egy újabb lehetőséget kínált: az ext3 journal gyors lemezre helyezését. Az SSD-k felépítéséből adódó minimális seek idő ideálisnak látszott a journal tárolására. Vásároltak egy OCZSSD2-1S32G (32GB SATA2 megoldás az OCZ-től) terméket, mert jó értékeléseket olvastak annak írási teljesítményéről. Elvégezték a megfelelő konfigurációs lépéseket, majd a következőket tapasztalák:

  • Az általános lassúság komolyabb írási tevékenység esetén csökkent, így már nem veszélyeztette a napi munkát
  • az általuk alkalmazott "hardlink backup" fele annyi ideig tart
  • szalagos mentés is körülbelül fele annyi ideig tart

A blogbejegyzés itt.

( NagyZ v | 2008. 09. 11., cs – 12:18 )

ezert szoktuk igazabol a journalt kulon diszktombre rakni. nalam ket db 32g -s 15krpm -es diszken van a journal. ez nem uj dolog :)

persze az SSD ujdonsagfaktor.

Én azt nem értem, hogy ha te ezt trivialitásnak érzed, akkor miért nem lépsz rajta túl szó nélkül? Az oldalt olvassák kezdők is, akiknek minden vicc lehet új. Hírértéke nincs, tán lehet, hogy ez nem is hír? Találkoztam már olyan rendszergazdával, akinek ilyesmiről fogalma sem volt.

Tipikusan olyan érzésem van az ilyen hozzászólásoknál, mint a moziban a mindenki által utált néző, aki századszorra látja a filmet, és az izgalmas jelenet előtt fennhangon mondja "most jön az, amikor levágja a fejét". Vagy a tanfolyamokon az általam annyira utált tudorbugyor, aki mindig egy kicsivel jobban tudja az oktatónál is és ennek öt percenként jelét is adja a közbekotyogásával.

Nem beszélve arról, hogy az ilyen problémák felvetése vitaindítónak sem utolsó, a hatására létrejövő értelmes hozzászólásokból tanulni lehet. Ez a lényege az ilyen fórumoknak.

--
trey @ gépház

"Szamomra is olyan szaga van, mintha a flash diszken lenne a hangsuly."

Igen, azon van a hangsúly.

"Ill. a cikket nem olvastam, de nem irta, miert nem probalta eddig, hogy a journalt egy kulon (normal) diszkre rakni?"

Erről nem szól a blogbejegyzés.

"Gondolom egyebkent a lenyeg az, h az ssd fajlagosan gyorsabb, rosszul tudom?"

Tippelem, hogy az SSD-k ezen jó tulajdonságát szerették volna hasznosítani.

--
trey @ gépház

Jelentkezem. Papir szerinti munkam rendszergazda, affelet is csinalok, de en mindig azt hittem, amelyik wincsin van az fs, azon van a hozza tartozo journal is. tune2fs max. arra volt jo, hogy x naponkent/mountolasonkent ne fsck-zon, vagy ne foglaljon 5% helyet a rootnak. Ezt sose neztem benne, hogy mashova is mehet a journal. De ezutan megfontolando.

( uid_228 | 2008. 09. 11., cs – 12:27 )

Egyeztessuk a hirt azzal, hogy flash eszkozre nem ajanlatos az Ext3, mert a journal alatt "kiegnek" az adatblokkok. Mivel itt ugyanugy a journalt irogatja a flash device-on, ez mitol mas? :)

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

És ha 2 év alatt kiég a journal disk, akkor mi lesz? Lemez ki, másik be, journal elkészít, minden megy tovább. Cserébe nem kellett foglalkozni két évig a problémával. Vagy én tudom esetleg rosszul, hogy a journal nélkül is mount-olható az ext3 ext2-ként? Ez nem járható út? Illetve próbálta már ezt valaki, akinek van tapasztalata arról, hogy mennyi idő alatt "ég ki" egy ilyen lemez ilyen terhelés alatt, vagy van ez a legenda és mindenki ezt szajkózza?

--
trey @ gépház

Attól függ, hogy hogy van implementálva rajta a wear levelling algoritmus. Ezt roppant nehéz kideríteni, mert nem látsz bele az eszközbe. Ha hinni lehet az Intel marketingnek, akkor a jelenlegi SSD-k csapnivalóan rosszak voltak ebből a szempontból, ezen akarnak változtatni ők az új SSD kontrollerükkel. Az idevonatkozó cikk egyébként itt olvasható http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=4.

A journal-nak az a szépsége, hogy egy egyszerű körbeforgó puffer adatszerkezetet használ, tehát az írás mindig szekvenciális. Ez egyrészt teljesítményszempontból kedvező az SSD-knek, mert jellemzően a random írásnál lassulnak be nagyon (ennek az okairól is van egy hosszabb fejtegetés a fenti cikkben). Másrészt pedig saját maga megoldja a wear levellinget is, hiszen mindnen teljes naplóírási körben az összes blokk pontosan egyszer van írva. Tkp. semmi extra wear levelling algoritmusra nincs szükség, akár direktben (MTD eszközön keresztül) is lehet a naplót nyomni a flashre.
---
Linux is bad juju.

Hát a journalt az SSD-re rakni az egy kitűnő próbája lesz a wear levelingnek. Remélem sok lesz az önkéntes tesztelő. Én még várok pár évet, amíg az árak lejjebb mennek és visszanézek a fickó blogjára, hogy mik a hosszú távú tapasztalatok.
Azért a CD és pláne a DVD sem váltotta be az adatbiztonsággal kapcsolatos kezdeti reményeket. Meg lehet nézni, hogy mennyibe kerül mondjuk egy "egészségügyi minőségű" (egészségügyi adatok hosszú távú archiválására alkalmas) DVD a boltihoz képest.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nemtom, hogy a szoftver RAID1-be kötött SSD spare lemezzel az nagyon perverz elképzelés lenne-e, egyáltalán működne-e és ha igen, akkor milyen teljesítménnyel.

Ehhez talán lazán kapcsolódik, hogy a Sun most nagyon nyomja a flash alapú adattárolást. A sebességet a SSD hozná az adatbiztonságot meg a ZFS.

Anything But a Flash in the Pan
Flash meghajtókat fog kínálni még ebben az évben a Sun a szervereihez
Storage Revolution!

--
trey @ gépház

"Nemtom, hogy a szoftver RAID1-be kötött SSD spare lemezzel az nagyon perverz elképzelés lenne-e, egyáltalán működne-e és ha igen, akkor milyen teljesítménnyel."

Szvsz működni biztos működne, elvileg meg ugye k. gyorsan is ráadásul.
Nincs kedved tesztelni, érdekelne enegm is a gyakorlatban? :)

a wear levelingnek is vannak hibái. például ha egy meghajtó már nagyon tele van, mondjuk egy 64 gigáson már csak 1-2 giga hely van, és a rajta lévő 62 giga adat nem módosul gyakran, akkor a wear leveling csak az üres helyen fogja az új írásokat elosztani. azaz az 1-2 giga hely még gyakrabban lesz írva, mintha sok szabad hely lenne a meghajtón. ettől ez a gyakran írt rész nagyon hamar tönkre fog menni.
a wear levelingnek minél több üres blokk kell, hogy a lehető leghatékonyabban dolgozhasson.

Csak tippelni tudok. Amíg nem SSD-n volt a journal, addig a komolyabb írási műveletek annyira lelassították az olvasást is, hogy mentés is lelassult. Mióta SSD-n van a journal, nem lassul le (annyira) az olvasás, így a backup is hamarabb végez. Végülis ezt írta le az ember.

--
trey @ gépház

( cstt v | 2008. 09. 11., cs – 14:52 )

Ti használtatók már linuxal SSD-t ?
Kell hozz valami extra vagy csak az SATA vezérlőn keresztül látja és kész ?

IDE-CF átalakító + talán 4GB CF kártya párossal használtam hasonlót...
logok központi szerverre mentek, az adatok meg SCSI diszkeken voltak, CF & ext3 meg a "rencer" helye... 3 évig adminkondtam a kicsikén, semmi gond nem volt vele. mini-ITXen akartam hasonló ház szervert, de rájöttem, h tetű drága lett volna még 2-3 éve is

( LGee | 2008. 09. 11., cs – 17:29 )

A szerzo amugy az mrtg es az rrdtool fejlesztoje is egyben...

( imi84 | 2008. 09. 11., cs – 18:54 )

tapasztalák

Ékes szépmagyarság vala.

Megmondta trey, hogy nem sziveli a cikkek nyelvi problemait kipellengerezo kommenteket. Mit mondjak, igaza is van. Ott a kapcsolati urlap, lehet szolni neki szepen is. Ne vard mar el, hogy egy tobbszazezer node-s rendszert folyamatosan olvasson. Link, cim, hibak. Lehet ezt kulturaltan is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Replaced | 2008. 09. 11., cs – 20:07 )

prestoserve visszavag :)

--
"Computer science is no more about computers than astronomy is about telescopes."