block device is write-protected

[Florian Lohoff]

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                                                 f at zz.de
     We need to self-defense - GnuPG/PGP enable your email today!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20151002/1ec832ea/attachment.sig>