mkfs.ex4 es mkfs.ext3 + tune2fs -O extents,uninit_bg,dir_index kozti kulombsegek

Naplózó filerendszerek (journaling)

Sziasztok!

XenServer -re telepitek CentOS 7 -et egyelore csak kiserlet keppen (PV guestkent).
Ha a /boot -ot ext3 -ra formazom, akkor minden rendben, ha viszont ext4 -re, akkor a pygrub elszall:

Sep 18, 2014 2:42:20 PM Error: Starting VM 'VMNAME' - Internal error: xenopsd internal error: VM = cf0e40bb-8c07-5a1d-454c-394e43e8c88e; domid = 57; Bootloader.Bad_error Traceback (most recent call last):
File "/usr/bin/pygrub", line 903, in ?
fs = fsimage.open(file, part_offs[0], bootfsoptions)
IOError: [Errno 95] Operation not supported

CentOS6 -on megy ugyan ez ext4 -gyel, sot, CentOS7 -en is, ha elobb ext3-kent hozom letre a /boot -ot es utolag kovertalom.

Mi a kulombseg a ketfele keppen letrehozott ext4 filerendszer kozott?

Koszonom.

  • 8003 megtekintés

( mauzi v | 2014. 09. 18., cs – 16:18 )

Futtass egy "tune2fs -l"-t mindkét esetben, és hasonlítsd össze a kimenetét.

( _ventura_ v | 2014. 09. 18., cs – 19:46 )

Melyik xenserver ? Mert nekem 6.2 esen sehogyse akart menni. Igy maradt a PVHVM mód.

Fedora 20, Thinkpad x220

( locsemege v | 2014. 09. 19., p – 14:51 )

Futtas egy sed-et a hozzászólásodra valahogy így:

sed 's/kulombseg/különbség/g'

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igaz hogy elég ritkán postolok a hup-ra, de sokszor a postoló kérdésének megformázása állít meg engem. Ha valaki segítséget kér, elvárnám hogy vegye a fáradságot hogy ékezetekkel ír, helyesírása megüt egy bizonyos színvonalat, értelmes mondatokat rak össze, stb. Aki erre nem képes, vagy nem veszi a fáradságot, azt én is kisebb eséllyel méltatom válaszra. Mondjuk (sajnos) említésre méltó pozitívum, hogy a kérdező legalább a -val/-vel ragok teljes hasonulásával tisztában van, sajnos ez is igencsak ritkaság napjainkban.

( vl v | 2014. 09. 20., szo – 12:45 )

Én speciel azt nem értem, hogy miért nem jó az ext3 annak a pár MB-nak... miért jó szopatni magadat?

Volt fejlesztő munkatársam nyilatkozata az ügyben 2012-ből:

"tudtommal a barriers enabled by default dolog az az ext4-el jott be, nem a kernellel, bar lehet h fstol flenul 3.x-tol a barrier aktiv minden fajlrendszernel ahol ezt tamogatja. (fokent az SSD-k trim tamogatasanak feltetele)

amugy minimalis sebesseg csokkenes aran, noveli az adatbiztonsagot.

az a lenyege h ugye tranzakcio elott bekerul egy bejegyzes a journalba. vegigfut a tranzakcio es utana tortenik egy commit a journalba es ennyi volt egy iras.

a barrier nelkul akkoris commit tortenik, amikor visszajelzest kapott az I/O subsystemtol h kiirodott, ami mar azelott visszajelez, mielott a winyo kisyncelte volna a cachet.
barrierrel meg csak akkro tortenik tenyleges commit, amikor tenyleg atvitte a cachet minden taroloreteg (persze a RAID kartyak hazudnak, de az meg feltetelezi magarol h van benne BBU, igy joggal hazudhat). (gyakorlatilag olyan mintha i/o transakcionkent tudnank kulon fsync-elni).

ugye ilyenkor az irasi folyamat ez:
kliens rendszer -> kliens i/o subsys -> pv driver -> vm backend driver -> bkltap/tapdisk -> hostgep i/o subsys -> hostgep driver -> storage hw

az a baj h a blktap/tapdisk reszben nincs implementalva ez a fajta fsync es a barrier tamogatas. raadasul a BARRIER flaget, amit megkap azt elnyeli, nem ir ra hibat h nem tamogatja, ilyesmi.
akkor lesz problema, amikor valami miatt leall a vm varatlanul, vagy intenziv io terheles ala kerul ugy hogy kieheztetodik valami. es ilyenkor a diszken az adatok es a journalban rogzitett tevekenysegek kulonbozni fognak.
ugye tul koran jelzett commitot a journalban, de az adat meg a regi a diszken (nem tudta kisyncelni). kovetkezonek onnan akar olvasni, latja h hibas a dolog, mivel fel volt huzva a barrier (az fs szemszogebol), tudja h ilyen nem lehet -> adatkorrupciot erzekel es ro-ba kapcsol, vagy elkezd szemetelni, ha pl egy inode tabla serult meg. ugye automatan nem fog fsckzni, majd egy journal rollbacket csinal, de itt meg nem derulnek ki az inkonzisztenciak.

elvielg opensource xenhez van nemhivatalos patch ezugyben."

A hibaüzenet egyébként a következő volt a futó vm konzolján: blkfront write barrier empty xvda op failed

Köszönöm, ez hasznos volt. Azon többször gondolkodtam, hogy a disk cache dolgairól még akár tudhat a kernel, de mi van akkor, ha a disk cache-ből sync-elte már az adatot, de az a HDD-ben lévő néhány MB cache-ben van, nem a mágneses adathordozón. Erről ad a HDD valamiféle státuszt? Ezt a kernel képes nyomon követni?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha a diszkben a write cache ki van kapcsolva, akkor a kernel pontosan tudja, hogy mikor került ki olyan helyre az adat, ahonnan nem veszik el: amikor a diszk visszajelez, hogy készen van.
Ha a diszk write cache be van kapcsolva, akkor még mindig van az az opció, hogy a diszk ismer olyan parancsot, amivel ezt bekapcsolt write cache mellett, per diszk írás el lehet érni (FUA), ami szintén a fenti eredményt hozza.
Aztán van az az opció, hogy nem ismer ilyen parancsot a diszk, ekkor meg azt tudja mondani az OS, hogy a cache-ben várakozó össze blokkot kéretik kiírni a diszkre, és amikor ez megvan, akkor tudni fogja a kernel, hogy minden kint van a diszken. Emlékeim szerint a barrier implementáció ez csinálja fallback-ként.

A barrier annak a technológiája, hogy a fs megmondja az alatta levő block device rétegeknek (beleértve a fizikai diszket is), hogy az írási műveletek között milyen kötelező sorrendiséget kell fenntartani a konzisztencia megtartásához. Gyakorlatilag arra használja a rendszer, hogy véletlenül se fordulhasson meg két írási művelet sorrendje, amit egyébként akár a block device layer, akár maga a diszk megtehetne, ha csak szimplán beszórod a két írást egymástól függetlenül.
Ha ezt kikapcsolod, akkor vagy le kell mondanod a konzisztenciáról (kihúzod az áramot/elpusztul a tápegységed, és a fájlrendszeredben random adatvesztés lehetséges), vagy teljes device synccel kellene ezt a fs-nek önerőből megoldania, ami sokkal drágább művelet. Nem tudok róla, hogy ez választható lenne, vagy az ext4 a második variációt választaná. Ergó barrier=0 + áramszünet jó eséllyel = szopás.

Csak a műkedvelők kedvéért, én ezekkel az opciókkal használom már jó pár éve az ext4-et minden probléma nélkül:
noatime,nodiratime,journal_checksum,journal_async_commit,barrier=1,data=journal,commit=10
Ennek megvan az a hibája, hogy nincs O_DIRECT. Szóval Oracle DB alá inkább saját raw device-t tennék.
Továbbá ha a root fs-t is így szeretné valaki használni, és modern disztribúciója van (ami szeretne initram-ból bootolni), akkor valamihogy rá kell vennie a rendszer által generált boot image-et, hogy ezekkel az opciókkal mountolja a root fs-t, mivel egyik-másik menet közben már nem állítható át.

( uid_6201 v | 2014. 09. 21., v – 23:47 )

Az ext4 konverziót rendesen megcsináltad? A tune2fs önmagában nem alakít át meglevő fájlokat, csak cimkével jelzi a fájlrendszer képességeit.

A fájlrendszer leválasztása után:
* tune2fs -O extents,uninit_bg,dir_index /dev/DEV
* e2fsck -fDC0 /dev/DEV

Az imént írt e2fsck után alakul ext4-gyé a meglevő fájlok tárolása.