A FreeBSD-s tábort sokáig cikizték azzal, hogy naplózó fájlrendszer híján egy-egy crash után (szerencsére ebből azért nem volt sok) percekig kell fsck-zni, míg helyreáll a rendszer. Aztán mikor megjelentek a több tíz GB-os diszkek, hosszú percekig. Aztán mikor ezeket a diszkeket RAID-be tettük, hosszú-hosszú percekig. Aztán mikor már száz GB-os diszkeket raktunk RAID-be, mert az UFS2 ezt megengedte, és ezeket a diszkeket jól megpakoltuk apró fájlokkal, akkor napokig is.

Aztán lett journaling fájlrendszer, pár próbálkozáson keresztül a ma talán leginkább használható a gjournal nevű (amelyből kettő is volt, Ivan Vorastól, és Pawel Jakub Dawidektől, itt ez utóbbiról lesz szó).

A gjournal -a nevéből adódik- a GEOM frameworkben ül, és ezáltal GEOM providereket naplóz blokkszinten, azaz elvileg az UFS mellett más fájlrendszerek is használhatják (de nem igazán fogják). A működéséhez az UFS-t kellett pár helyen módosítani, hogy a fájlrendszer-journal kapcsolat valamelyest teljesüljön, de a blokkszintűségből adódik, hogy más megoldásokkal szemben ez mindent naplóz, legyen az metaadat, vagy adat.

A napló amúgy egy fix méretű helyet jelent akárhol. Lehet azon az eszközön, amelyen maga a fájlrendszer, de lehet külön is.

A működése egyszerű, a legfontosabb állítható paraméter a journal váltási ideje, és a cache mérete. Ha ezek letelnek (és volt írás persze), a gjournal lezárja a journalt, újat kezd, és kiírja a lezárt tartalmát az adatdiszkre. Mivel a journal írása szekvenciális, a journalba írás nagyon gyors, függetlenül az írás jellegétől. Persze utána azt az adatot ki kell írni a diszkre is, az meg már nem lesz annyira Speedy Gonzales (Andale!).

Szóval a gjournal használata (külön journal diszk(ek)kel) gyorsíthat is akár, de persze a legfontosabb, hogy meggátolhatja az fsck-t (a hangsúly a feltételes módon van, ugyanis van, hogy ez nem teljesül, és fsck-zni kell, ez pedig érhet minket készületlenül).

A mérleg másik nyelve a jó öreg soft updates a legendás Kirk McKusicktól, amely úgy próbál játszani az írási műveletekkel, hogy a fájlrendszer integritása ne sérüljön, és fsck nélkül is működőképes maradjon (a soft updates-szel mountolt fájlrendszert tehát nem kell fsck-zni, egy lerohadás után anélkül is lehet használni, az fsck (amely tud háttérben is futni, jól lelassítva a gépünket) csak a levegőben lógó bejegyzéseket szabadítja fel, meg persze ha valami fájlrendszer korrupció volt, azt javítja -ha ilyenünk van, az fsck nélküli indítással egy vaskos panicot kockáztatunk-).

Na de nézzük a grafikonokat, FreeBSD 8 soft updates vs. gjournal egy darab 72 GB-os szingli 15k RPM-es SAS diszken:

A leglátványosabb grafikon a szekvenciális írás, ahol a gjournal négyszeresen ráver a soft updates-re nagyon pici blokkméreteknél. Ez nyilván annak köszönhető, hogy míg az UFS azon görcsöl, hogy mit is tegyen a fájlrendszer blokkmérete (16 kiB) alatti írással, addig a gjournal valóban szekvenciálisan kiírja a journalba, aztán amikor pedig a diszkre másolja, a RAID kontroller cache-ének segítségével már nagyobb adagokban tud folyni az adat a diszk felé.

A fájlrendszer blokkmérete gyönyörűen látszik szinte mindenhol, itt nagy ugrások vannak az optimális kiosztás miatt. Megmutatkozik a SAS diszk ereje is, amit a magas forgási sebesség, és a (viszonylag) gyors seekeléseknek köszönhet.

Nézzük ugyanezt MiBps-ban!

A szekvenciális olvasásnál látszik az adatdiszken tárolt napló legnagyobb hiányossága: a dupla írás. Soft updates-szel a diszk kb. 90 MiB-ot képes benyelni másodpercenként, amit a journalnál (némi overheaddel) duplán ki kell, hogy használjon a gép, azaz az írási teljesítmény feleződik.

Ami látványos, hogy ezt a maximumot már alacsony blokkméretnél (4 kiB) eléri, és utána tartja is, azaz ha lett volna még egy ugyanilyen diszkünk logdiszknek, kis blokkméreteknél igen jelentősen növekedett volna az áteresztőképesség.

Az életszerűbb random írás tesztekben viszont nagyobb nyert a soft updates, azaz akinek ilyen jellegű a workloadja, és megengedheti, használjon inkább olyat (vagy próbálja meg külön tenni a journalt), ezek szerint jobban jár.

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.