SWRAID[56] BSoD és adatvesztés

Fórumok

Üdv,

Mint tudjuk, barriers nélkül a fordított sorrendű írás simán adatvesztést okozhat bármilyen átlagos naplózó fájlrendszernél. Az ugye köztudott, hogy a winyók writeback cache-e áramszünet esetén gyakori felelőse a fájlrendszer korrupcióknak.

Most viszont "sima" kernel panic-ok után lett korrupt a RAID6-os XFS fájlrendszerem, pedig semmiféle ''mdadm --force'' -ot nem használtam és áramtalanításról szó sincs. A BSOD oka egy experimental hw driver, de ez más téma. A kérdés, hogy hogy történhetett ez? (nem hiszem, hogy XFS hiba)

A tippem az, hogy az SWRAID[56] barriers nélkül nem figyel arra, hogy az adatok megfelelő sorrendben legyenek kiírva. Emiatt -a szóló winyó WB cache-ével ellentétben- egy rosszkor jött BSOD is elég ahhoz, hogy egy fordított sorrendű írás úgy maradjon félbe, hogy korrumpálja a fájlrendszert. Valaki ezt meg tudja erősíteni?
(Guglival nem találok semmit a témában, pedig biztos ki volt már valahol tárgyalva, egy link is elég lenne. thx)

UPDATE: továbbra se találok tuti infót, de teljesen logikus, hogy felborul a sorrend az SWRAID[56] miatt, hiszen másképp csak sorban írhatnának a diszkek, ami a leglassabb diszk sebességére korlátozná az írás sebességet, ami nyilvánvalóan nem így van.

Hozzászólások

1. Szerintem a HDD-k sosem cache-elnek irast. Ha igen, akkor sehogyse lehetne garantalni az adatok integritasat aramszunet eseteben.
2. Az XFS arrol hires, hogy aramszunet eseten gyakori az adatvesztes. Ez az eset csak megerositi ezt a megfigyelest.

Áramszünettől a szünetmentes sem véd, csak az áramszünet következményeitől...
Ha normális oprendszert használunk, abban általában kevesebb a kernel pánik, mint áramingadozás/áramszünet/áramkimaradás.
Kernelpánik esetén az esetek többségében még van idő IO syncre, amit egy kulturált kernel végre is hajt...

Kernel pánik ellen a megoldás, hogy nem használunk kernelt... (->papír, ceruza, zsebszámológép.) :)

VAX/VMS-hez van szerencsénk?

Komolyan, eljutottunk 2011-re oda, hogy szorgos kínai kezek a minőségre (és sokminden másra) sem ügyelve legyártanak hardvereket, amikre még szorgosabb indiai kezek szoftvert fejlesztenek szintén mennyiségi alapon (=kilóra), amit aztán marketingesek a piac nyomására alfa állapotban kiadatnak és ahol a vásárló valójában a bétateszter és mire a szoftver valójában jó lenne, addigra elpusztul alatta a hardver, elmúlik a hype és már a hárommal újabb verzóval etetik azt a felhasználót, aki a régi verzióból sem tudott kihasználni 5%-nál többet...

"Szerintem a HDD-k sosem cache-elnek irast..."

Hogy a fenébe ne... Kb mindegyik. Viszont kikapcsolható. Tetű lassú is lesz tőle.
Ha veszel egy normális BBWC raid adaptert, azok is ki szokták kapcsolni a diszk cache-eket, mivel áramszünet esetén a BBWC is csak akkor véd, ha diszk write cache nincs.

"Ha igen, akkor sehogyse lehetne garantalni az adatok integritasat aramszunet eseteben."

De. UPS.
Szünetmentes nélkül már csak a file rendszer write cache miatt sem lehet garantálni az adatintegritást...

Akkor a kerdesem az, hogy amikor a filerendszer uriti a write cache-set, akkor betartja a write ordert?
Mert ha igen, akkor nyilvan lesz adatvesztes (amit az utolso nehany masodpercben irtak a programok), de legalabb a kiirt adat "power-fail" konzisztens lesz, amit a naplozo filerendszerek mar tudnak kezelni.

"Akkor a kerdesem az, hogy amikor a filerendszer uriti a write cache-set, akkor betartja a write ordert?"

Lásd vl kolléga korábbi hozzászólását.
Ha a file rendszer kezeli a barriert, akkor igen. Vagyis a kiírt adatok (az utolsó barrier blockig) file rendszer szinten konzisztensek.
Ez még nem jelenti azt, hogy alkalmazás szinten is konzisztens lesz, ha az alkalmazás nincs ilyesmire felkészítve. (Erre utaltam, mikor azt írtam, hogy az oprendszer write cache esetén nincs garancia a konzisztenciára.)

Adatbázisok esetén sokszor ki is szokták kapcsolni az oprendszer fs. cache-et, részben konzisztencia okok miatt, részben meg azért, mert a legtöbb adatbázis is csinál saját blokk szintű cache-elést. (lásd: double buffering probléma).

Passz. Gondolom sokat javít a dolgon, cserébe szerintem gyalázatos lesz a teljesítmény.
Nem szoktam ennyire paranoid lenni, egy journaling file rendszer bekapcsolt diszk cache-el számomra eddig a legtöbb esetben elég volt, főleg ha valamilyen ups-el is védve van. Szerintem. (és persze backup, backup, és backup...)

Ha valahol meg kritikus az adatintegritás, és sebesség is kell, oda lehet venni egy elemmel védett cache-vel rendelkező raid adaptert.

A barrier működik DM-en és MD-n át is 2.6.33 óta.

Ha használtam volna, akkor valszeg nekem se sérül le az FS.

Egy probléma lehet meg barrier mellett is, ha a journal írása szakad félbe. Ez ellen csak az ext4 véd a journal checksum-al, a többi fájlrendszer a hibás log visszajátszásánál elcseszheti a metaadatokat.

Szóval biztonságos swraid = 2.6.33+ + barriers + ext4.

Ha elhiszed egy olyannak aki nemrég vesztett egy fél fájlrendszert. :D

nem tudom, mi az igazság. A linkelt blog szerint a device mappertől függ a dolog, és nem a kerneltől vagy file rendszertől.

szerk: Közben találtam olyan utalást, hogy az újabb kernelek egyre inkább támogatják a barrier módot a teljes stacken keresztül. Szóval a probléma megoldása a try and error módszer.... :)

1. Szerintem a HDD-k sosem cache-elnek irast. Ha igen, akkor sehogyse lehetne garantalni az adatok integritasat aramszunet eseteben.

A vinyók tudnak write behind cache-inget.
Az átlagos mezei desktop vinyót úgy árulják, hogy ez default on.
Az átlagos szerver vinyót úgy árulják, hogy ez default off.

Tök ugyanazt a Seagate SATA vinyót megveheted a sarki pc boltban, és default on lesz, míg egy x2200-asban meg - ugyan Sun-logós lesz a diszk, de - default off lesz.

Bekapcsolt write cache mellett is garantálható a fájlrendszer konzisztenciája, ha a fájlrendszer tud barrier-t kezelni, és a write cache flush művelet eljut a fájlrendszertől a diszkhez. Persze egyszerűbb kikapcsolni azt a write cache-t, és igazából szükség sincs rá (van elég memória a gépben, cache-eljen az, ráadásul a gép tudja, hogy mit nem szabad cache-elni, és mit igen).

Az adatok el nem vesztéséhez ez kevés, hiszen a fájlrendszer nem garantálja a fájlok tartalmának tranzakcionális kezelését, ahhoz - pl. egy RDBMS esetén - kell az alkalmazás részéről is a megfelelő write cache flush művelet használata (fsync), aminek ráadásul működnie is kéne.

2. Az XFS arrol hires, hogy aramszunet eseten gyakori az adatvesztes. Ez az eset csak megerositi ezt a megfigyelest.

Az XFS emlékeim szerint defaultból barrier off flaggel mountolódik, ami felhívás keringőre fs inkonzisztencia szempontjából. Nem meglepő a hírhedtsége.

Well, the term “Blue Screen of Death” was not the original acronym for BSOD. The original term meant the “Black Screen of Death” and was seen when running under Windows 3.0. -- http://weblogs.asp.net/wallym/archive/2004/02/20/77425.aspx

Szerintem tök mindegy, hogy blue vagy black, remek platformfüggetlen kifejezés a kernel panicra.