On Wed, Sep 30, 2015 at 09:22:32AM +0200, Ralph Meyer wrote: > Hallo, > Da steht dann sowas : > > Buffer I/O error on device dm-2, logical block 30671861 > lost page write due to I/O error on dm-2 > sd 2:0:2:0: timing out command, waited 1080s > sd 2:0:1:0: timing out command, waited 1080s > sd 2:0:1:0: timing out command, waited 1080s > sd 2:0:1:0: timing out command, waited 1080s
Also wenn das wirklich 1080 Sekunden waren hat der mehr als 1ne Stunden auf den i/o gewartet ;) > JBD2: Detected IO errors while flushing file data on dm-2-8 > Aborting journal on device dm-2-8. > EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted > EXT4-fs error (device dm-2): ext4_journal_start_sb: > EXT4-fs (dm-2): delayed block allocation failed for inode 6562770 at logical > offset 148216 with max blocks 1 with error -30 So - hier hat dann EXT4 erkannt das mittendrin er nicht mehr auf das FS schreiben kann. Damit hat sich am filesystem nichts geändert. Im Speicher hat sich der kernel dann gemerkt das das filesystem inkonsistent oder kaputt ist. Verweigert also weiteres schreiben selbst wenn der block layer darunter wiederkommt. Da brauchst du mind. ein unmount/mount damit da irgendwas wieder geht. Man könnte gucken ob man dem JBD layer beibringen kann unendlich zu warten wenn es zu einem i/o timeout kommt. Damit kann obiges nicht passieren. Die VM hängt dann zwar in dem moment wo das SAN unerreichbar wird, würde aber wieder loslaufen wenn es weitergeht. > > Ich kenne jetzt das Thema ESX nicht so - Als was sieht denn die VM die > > Platten? So wie ich den ESX verstanden habe ist das ja ein ziemlich > > minimaler hypervisor ... Vielleicht liegt das problem aber ja ausserhalb > > der VM - d.h. der host sieht die devices schon als read-only? > > Ich mich auch nicht wirklich. Mir ist da aber auf die Schnelle nichts bekannt. > Dagegen würde ja auch sprechen, das nach einen Reboot alles wieder in Ordnung > ist. > Was auch dagegen sprechen würde, Windows VMs laufen, nachdem das SAN wieder > da ist, > einfach weiter. Nichts mit read only oder so. Die warten oder retryen halt den i/o solange bis der geht. Irgendwann geht das SAN wieder und die laufen weiter als sei nichts gewesen. Schnelles googlen brachte nur VMWare KB Artikel über das tunen der timeout values der block devices. Da kann man natürlich auch 86400 rein schreiben - dann wartet der halt einen tag. Die frage ist ob das geht. wenn da im FC mal ein command verloren geht dauert das halt auch so lange. Flo -- Florian Lohoff [email protected] We need to self-defense - GnuPG/PGP enable your email today!
signature.asc
Description: Digital signature
-- Linux mailing list [email protected] subscribe/unsubscribe: http://lug-owl.de/mailman/listinfo/linux Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo
