У меня проблемы с сервером Dell 1950. Я устанавливаю здесь RHEL 4.6 вместе с Oracle и некоторым другим программным обеспечением.
Я случайным образом получаю сообщение об ошибке "kernel: journal commit I / O error" в моем сеансе ssh и на мониторе, который я подключил к серверу, я вижу прокручивающуюся ошибку с надписью "EXT3-fs error (device sda5)" в start_transaction: журнал прерван. "
Это происходило несколько раз, но никогда в один и тот же момент во время установки. Фактически, в этот последний раз система была запущена и я просто пытался импортировать базу данных в Oracle.
Это произошло на нескольких жестких дисках, поэтому я почти уверен, что проблема не в этом. Это заставляет меня думать, что рейд-контроллер выходит из строя.
Что, вы парни, думаете?
** ОБНОВИТЬ **
Почти уверен, что это был плохой жесткий диск. Я вставил в сервер еще один диск, и он проработал около 48 часов без проблем.
Я видел эти ошибки раньше, но не в процессе установки.
Это означает, что накопитель получил достаточно ошибок, чтобы ОС перевела его в режим только для чтения. Если бы вы могли найти полные журналы, вероятно, были бы некоторые ошибки ввода-вывода, которые выполнялись повторно и работали до ошибок полного отказа, которые вы видели. Что-то с упомянутыми реальными блоками.
Это ошибка системы хранения. Это определенно карта RAID, диски в массиве RAID, кабели от карты к дискам, объединительная плата, к которой подключаются диски, слот, в который вставлена карта RAID, источник питания для жестких дисков или что-то еще в между ЦП и фактическими блоками хранения.
Возможно, RAID-контроллер выходит из строя, как вы сказали (попробуйте запасной, если он у вас есть). Это может быть драйвер для контроллера (проверьте наличие альтернативных драйверов, если они доступны, даже если производительность хуже, хорошо иметь контрольную точку .) Это может быть ядро (что менее вероятно, хотя в RHEL оно довольно хорошо протестировано). Это может быть плохая оперативная память, испорченная кеш-памятью блоков.
Однако наиболее вероятной причиной является аппаратная проблема, основанная на кажущемся случайным поведении ошибки.
На ум приходят три возможности:
Есть проблемы с памятью (они часто вызывают "случайные" сбои). Если у вас там есть плунжер ECC, то, очевидно, это менее вероятно.
Возникла проблема с автобусом. У меня была такая же проблема со сломанным контроллером APIC на материнской плате Tyan Dual Opteron несколько лет назад. Были и другие записи в журнале, которые намекали на это, но основная часть симптомов заключалась в случайном повреждении дисков с автоматическим повторным подключением только для чтения. В моем случае я знал, что это не связано с диском, потому что это был внешний блок FC RAID, и это было нормально.
RAID-контроллер двухъярусный.
Это в том порядке, в котором я бы рассмотрел проблемы.
Убедитесь, что диск не заполнен - в частности, корневой раздел. Используйте df, чтобы увидеть использование диска файловой системой:
df -h
Ищите перегородки, близкие или равные 100% загрузке
пытаться:
выключение -rF сейчас