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