Andrew Morton: Linux 2.6.6-mm5

Kernel

Andrew kiadta az -mm5 patchet a 2.6.6-os stabil Linux kernelhez. Benne egy érdekes új funkció, amely a ``request barriers'' névre hallgat.

A request barriers az IDE és SCSI merevlemezeken létrehozott journaling filerendszerekhez használható. Az request barriers azon az elgondoláson alapul, hogy a filerendszer képes egy IO kérést felcímkézni (tag) úgy, hogy azt egy barrier-nek jelöli (akadály), és a lemez nem fogja az írást úgy átrendezni, hogy túlnyúljon a barrier-en. Ezzel a módszerrel a filerendszer integritása sokkal jobban garantálható.

Az új funkció jelenleg két naplózó filerendszerrel használható. Az egyik a ReiserFS a másik pedig az ext3.

Használata: Miután lefordítottuk, és bebootoltunk az -mm5 kernellel, az alábbi műveleteket kell elvégezni:

ReiserFS:

-----------

# mount /dev/hda /wherever -o barrier=flush

vagy

# mount /dev/hda /wherever -o barrier=none

Ext3:

------

# mount /dev/hda /wherever -o barrier=1

vagy

# mount /dev/hda /wherever -o barrier=0

Az ext3 ezen felültámogatja a remount-ot is, az alábbi módon:

# mount -o remount,barrier=N

Andrew nem próbálta a remount-ot a ReiserFS-sel, így akinek van kedve próbálja ki.

MIVEL EZ EGY ÚJ KÓD, TERMÉSZETESEN ÉLNEK A SZOKÁSOS FIGYELMEZTETÉSEK. NE ÉLES ADATON PRÓBÁLJUK KI LEHETŐLEG!

A patchben egyébként változott még a VFS's symlink ``bejáró'' kód, található benne pagecache radix-tree spinlock munka, és egy új SATA RAID driver is a 3ware kártyákhoz.

Az anyag letölthető innen.

A változások listája Andrew levelében itt.

A kernel patcheléshez segítséget itt talász.

( nevergone v | 2004. 05. 22., szo – 18:19 )

Ennek a "request barriers" -nek, azon kívűl hogy hasznos, milyen káros (kellemetlen) hatásai lehetnek? Azt leszámítva, hogy új kód, és ezért veszélyes lehet. Milyen rendszeren (milyen helyzetben) csökkentheti a teljesítményt...?

( vmiklos | 2004. 05. 22., szo – 18:22 )

"Ezzel a módszerrel a filerendszer integritása sokkal jobban garantálható."

ez mit jelent? ;-)

gondolom kevesbe lesz szetszort az adat a lemezen, kovetkezeskepp kevesebb seek-elessel lehet majd azt visszaolvasni. magyarul kevesbe lesz toredezett a filerendszer, ha egyaltal lehet ilyet mondani a journaling FS-eknel (persze ezek csak ez en gondolataim, mivel sokkal tobbet nem lehet a dologrol tudni, es ahogy olvasom, mer Andrew-nek sincs minden tudas a birtokaban a errol a funkciorol)

Szerintem nem errol van szo.

Ez arra utasitja a diszket, hogy a megjelolt adatcsomagokat rogton kiirnia es ne rendezgesse a sajat belso memoriajaban (a kevesebb fejmozgas, igy nagyobb teljesitmeny eleresenek celjabol), hisz megtortenhet, hogy a journaling fs mar biztonsagosan kirt minden adatot "az IDE/SCSI buszra", de a vinyo meg a sajat memoriajaban szoszmotol (igy nem irodott lemezre) es akkor szunik meg a tapellatas...

(persze ez is csak tipp)

kerneltrap:

"Request barriers, also known as write barriers, provide a mechanism for guaranteeing the order of disk I/O operations without actually waiting for the data to be written to disk. Specifically, a request barrier guarantees that any data queued up prior to the the barrier will be written to disk before data queued up after the barrier. Without a request barrier, the block layer can reorder how data is written to disk for maximum performance. The problem with this being most notably with journaling filesystems which require that their metadata be updated prior to actually updating data, allowing true crash recovery. Without request barriers, a journaling filesystem has to wait for the metadata change to be written to disk before it can proceed with actually updating the filesystem."

Eszerint tenyleg ha egy ilyen csomagot kap azt elobb irja ki mint amiket utana, ezzel jelentosen megkonnyitve a journalling fs-ek dolgat

Egyetértek!

Szerintem is arról van szó hogy hiába van még 5 adatcsomag amit a lemez elejére kéne kiírni, és hiába van ott a fej, ez a 'barrier' arra fogja kényszeríteni hogy a másik adatot írja ki előbb még akkor is ha nem hatékony.

nevergone: IMHO itt a biztonságról van szó, ettől max csak lasabb lehet...