Мой сервер выходит из строя, и я не могу найти ответ, почему. Все началось после того, как мой центр обработки данных увеличил объем оперативной памяти с 16 ГБ до 32 ГБ.
Я тоже нашел такие логи в dmesg - они начали проявлять себя как раз перед первой паникой ядра:
EXT4-fs error (device md2): ext4_ext_find_extent: bad header/extent in inode #97911179: invalid magic - magic 5f69, entries 28769, max 26988(0), depth 24939(0)
EXT4-fs error (device md2): ext4_ext_remove_space: bad header/extent in inode #97911179: invalid magic - magic 5f69, entries 28769, max 26988(0), depth 24939(0)
EXT4-fs error (device md2): ext4_mb_generate_buddy: EXT4-fs: group 20974: 8589 blocks in bitmap, 54896 in gd
JBD: Spotted dirty metadata buffer (dev = md2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
EXT4-fs error (device md2): ext4_ext_split: inode #97911179: (comm pdflush) eh_entries 28769 != eh_max 26988!
EXT4-fs (md2): delayed block allocation failed for inode 97911179 at logical offset 1039 with max blocks 1 with error -5
This should not happen!! Data will be lost
EXT4-fs error (device md2): ext4_mb_generate_buddy: EXT4-fs: group 21731: 5 blocks in bitmap, 60762 in gd
JBD: Spotted dirty metadata buffer (dev = md2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
Моя система - 64-битная CentOS 5.8 с последним ядром 2.6.18-308.20.1.el5. Как я могу проверить причину паники ядра, не имея доступа к KVM?
Я сказал администраторам центра обработки данных проверить память на сервере.
Возможно, вы можете увидеть пакет netconsole, который регистрируется по протоколу UDP на другой машине, ядро ведет журнал в грубом режиме (не в системном журнале). На сервере вы должны установить netconsole и попросить его экспортировать на сервер журнала на основе примера «nc». В случае паники ядра вся информация записывается в журнал, и вы можете начать анализировать, что произошло.