Re: block device is write-protected
Hallo,
Ich hab schon blockdev --setrw probiert. blockdev --getro sagt 0. mount -o remount,rw ist aber immer der Meinung das /dev/mapper/lvm-fs write-protected ist.
lvscan --ignorelockingfailure sagt ACTIVE .
Ist die einzige Möglichkeit ein Reboot ?
Ich würde mir ja mal das dmesg ansehen bzw das dmesg des hosts. Zur zeit des ausfalls wird ja was in den kernel buffer gelogged worden sein. Da wird ja vielleicht ein hinweis sein wer jetzt für die read-only geschichte verantwortlich ist.
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 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 This should not happen!! Data will be lost EXT4-fs error (device dm-2) in ext4_da_writepages: Journal has aborted EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted EXT4-fs error (device dm-2) in ext4_reserve_inode_write: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted EXT4-fs error (device dm-2) in ext4_free_blocks: Journal has aborted Detected aborted journal
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. Ralph
On 09/30/2015 09:22 AM, Ralph Meyer wrote:
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.
Ralph
Hi! Ich hatte diese Woche ebenfalls mal eine Unterbrechung der Anbindung zum Storage. Die Linux VMs brauchten zwingend ein Reboot und zum Teil auch ein fsck, um das ext4 Journal wieder zu reparieren. Die Windows VMs haben das alles ohne reboot überlebt. Jörn
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@zz.de We need to self-defense - GnuPG/PGP enable your email today!
Teilnehmer (3)
-
Florian Lohoff
-
Joern Stenkamp
-
Ralph Meyer