DutchTSE
14/09/10, 13:25
Ik heb weer een vreemd probleem aan de gang. Wij draaien een berg ESXi servers met 1 virtuele server op 1 harde schijf. Nu komt het zo nu en dan voor dat op 1 server het filesystem read-only gaat en de volgende errors toont:
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 858382499
Buffer I/O error on device dm-4, logical block 3233868
lost page write due to I/O error on dm-4
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 860694027
Buffer I/O error on device dm-4, logical block 3522809
lost page write due to I/O error on dm-4
[....]
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 845755683
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 845851547
sd 0:0:0:0: SCSI error: return code = 0x00010000
[...]
EXT3-fs error (device dm-2): ext3_find_entry: reading directory #95518721 offset 0
Aborting journal on device dm-2.
[...]
Aborting journal on device dm-4.
ext3_abort called.
EXT3-fs error (device dm-4): ext3_journal_start_sb: <2>ext3_abort called.
EXT3-fs error (device dm-4): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
Detected aborted journal
ext3_abort called.
EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
Meestal is het na een reboot en een fsck verholpen, soms blijft het probleem en vervang ik de harde schijf die na controle volledig gezond blijkt te zijn (in windows, met smart tooltjes). We hebben de disk timeout op de virtuele servers al verhoogd van 180 seconden naar 360 en dit leek te helpen, echter komt het nog steeds incidenteel voor. Op sommige servers is het 1x gebeurd en daarna nooit meer (we hebben het nu over 10+ incidenten).
Iemand bekend met dit probleem of iemand die zijn diagnose erop los kan laten? Ik vermoed dat de virtuele server het te druk krijgt waardoor de storage binnen de VM te lang geen reactie van de host krijgt, echter is daar die disk timeout juist voor.
Clients draaien allemaal CentOS met vmware tools geinstalleerd. ESXi hosts zijn allemaal 4.0 met update 1 of 2, maar lang niet alle hosts zijn volledig up2date.
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 858382499
Buffer I/O error on device dm-4, logical block 3233868
lost page write due to I/O error on dm-4
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 860694027
Buffer I/O error on device dm-4, logical block 3522809
lost page write due to I/O error on dm-4
[....]
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 845755683
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 845851547
sd 0:0:0:0: SCSI error: return code = 0x00010000
[...]
EXT3-fs error (device dm-2): ext3_find_entry: reading directory #95518721 offset 0
Aborting journal on device dm-2.
[...]
Aborting journal on device dm-4.
ext3_abort called.
EXT3-fs error (device dm-4): ext3_journal_start_sb: <2>ext3_abort called.
EXT3-fs error (device dm-4): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
Detected aborted journal
ext3_abort called.
EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
Meestal is het na een reboot en een fsck verholpen, soms blijft het probleem en vervang ik de harde schijf die na controle volledig gezond blijkt te zijn (in windows, met smart tooltjes). We hebben de disk timeout op de virtuele servers al verhoogd van 180 seconden naar 360 en dit leek te helpen, echter komt het nog steeds incidenteel voor. Op sommige servers is het 1x gebeurd en daarna nooit meer (we hebben het nu over 10+ incidenten).
Iemand bekend met dit probleem of iemand die zijn diagnose erop los kan laten? Ik vermoed dat de virtuele server het te druk krijgt waardoor de storage binnen de VM te lang geen reactie van de host krijgt, echter is daar die disk timeout juist voor.
Clients draaien allemaal CentOS met vmware tools geinstalleerd. ESXi hosts zijn allemaal 4.0 met update 1 of 2, maar lang niet alle hosts zijn volledig up2date.