Dmesg переполнен ошибками ввода-вывода, все в порядке, четыре диска затронуты

Я работаю на удаленном сервере (Dell Poweredge), который был новой установки. Он имеет четыре диска (2 ТБ) и 2 SSD (250 ГБ). Один SSD содержит ОС (RHEL7), а четыре механических диска в конечном итоге будут содержать базу данных оракула.

Попытка создать программный RAID-массив привела к тому, что диски постоянно помечались как неисправные. Проверка dmesg выводит множество следующих ошибок:

[127491.711407] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719699] sd 0:0:4:0: [sde] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127491.719717] sd 0:0:4:0: [sde] Sense Key : Aborted Command [current]
[127491.719726] sd 0:0:4:0: [sde] Add. Sense: Logical block guard check failed
[127491.719734] sd 0:0:4:0: [sde] CDB: Read(32)
[127491.719742] sd 0:0:4:0: [sde] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127491.719750] sd 0:0:4:0: [sde] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127491.719757] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719764] Buffer I/O error on dev sde, logical block 488378260, async page read
[127497.440222] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.440240] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.440249] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.440258] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.440266] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.440273] sd 0:0:5:0: [sdf] CDB[10]: 00 01 a0 00 00 01 a0 00 00 00 00 00 00 00 00 08
[127497.440280] blk_update_request: I/O error, dev sdf, sector 106496
[127497.901432] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.901449] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.901458] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.901467] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.901475] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.901482] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.901489] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911003] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.911019] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.911029] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.911037] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.911045] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.911052] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.911059] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911067] Buffer I/O error on dev sdf, logical block 488378260, async page read

Эти ошибки происходят для всех четырех механических дисков, (sdc / sdd / sde / sdf) SMARTctl прошел все четыре диска, длинные и короткие тесты. В настоящее время я использую badblocks (тест режима записи ~ 35 часов, возможно, еще 35).

Ниже приведены ошибки, которые я подозревал / учел при исследовании

Отказ жесткого диска - маловероятно, что 4 "восстановленных" диска будут DOA, не так ли?
Проблема с контроллером хранилища (плохой кабель?) - Похоже, это повлияет и на SSD?
- Проблема с ядром. Единственное изменение в стоковом ядре - добавление kmod-oracleasm. Я действительно не понимаю, как это вызвало бы эти сбои, ASM вообще не настроен.

Еще одним заслуживающим внимания событием было то, что при попытке обнуления дисков (часть раннего устранения неполадок) с помощью команды $ dd if = / dev / zero of = / dev / sdX были получены эти ошибки,

dd: writing to ‘/dev/sdc’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70583 s, 32.0 MB/s
dd: writing to ‘/dev/sdd’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70417 s, 32.0 MB/s
dd: writing to ‘/dev/sde’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71813 s, 31.7 MB/s
dd: writing to ‘/dev/sdf’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71157 s, 31.9 MB/s

Если бы кто-нибудь здесь мог поделиться некоторым пониманием того, что может быть причиной этого, я был бы благодарен. Я склонен следовать бритве Оккама и идти прямо к жестким дискам, единственное сомнение связано с вероятностью четырех неисправных жестких дисков из коробки.

Завтра я поеду на площадку для осмотра и доложу о своей оценке этой машины вышестоящим сотрудникам. Если есть что-то, что я должен осмотреть физически (кроме кабелей / соединений / источника питания), пожалуйста, дайте мне знать.

Спасибо.

— Scu11y
источник

Когда вы говорите SMART «хорошо», вы имеете в виду общее состояние здоровья? Есть ли ненулевые отдельные счетчики для перераспределенных или ожидающих секторов? Диски не сразу объявляют себя неисправными в первом плохом секторе, даже если они не читаются. Используйте smartctl -x /dev/sdaили что-то. Но очень подозрительно, что это один и тот же LBA на всех дисках.

— Питер Кордес

Ваши ddтесты показывают, что все четыре диска не работают по одному и тому же адресу LBA . Поскольку крайне маловероятно, что все четыре диска выйдут из строя в одном и том же месте, я сильно подозреваю, что это связано с проблемами с контроллером или кабелями.

— shodanshok
источник

Трудно сказать без дальнейшего тестирования. В любом случае, первое, что я хотел бы контролировать / заменить, - это кабели, соединяющие контроллер с объединительной панелью.

— Сёданшок

Кабели с высокой скоростью передачи данных, такие как SATA / SAS 6/12 Гбит / с, предназначены не только для обеспечения электрической непрерывности, но главным образом для четкости сигнала и низкого уровня шума. Попробуйте физически очистить разъемы и снова подключите кабели. Если ошибка сохраняется, попробуйте изменить их и, наконец, попробуйте другой контроллер.

— Сёданшок

Та же LBA кажется маловероятной проблемой каблирования. Если только данные в этом секторе не являются битовой последовательностью наихудшего случая для некоторого скремблирования (чтобы предотвратить расширенные прогоны с подавлением автоблока «все ноль») или ECC по каналу SATA / SAS. Я не уверен, какую кодировку использует эта ссылка. Контроллер правдоподобен, хотя; один и тот же LBA на каждом из нескольких дисков требует своего рода объяснения общего фактора.

— Питер Кордес

@ djsmiley2k Трудно, чтобы все четыре ddконца кэшировались на одном и том же адресе ОЗУ. Кроме того, DRAM PERC защищена ECC, и, хотя ECC RAM также выходит из строя, это относительно редко. Тем не менее, контроллер может быть источником проблем, поэтому, если замена кабелей не помогает, OP должен попытаться заменить контроллер.

— Сёданшок

Ну, друзья мои, вы были правы. Кабели + контроллеры поменялись местами и теперь 600 ГБ в процессе обнуления дд и без ошибок до сих пор. Похоже, теперь все работает правильно. Еще раз спасибо за все знания, которыми вы поделились. Я всегда благодарен этому сообществу за ваш опыт и готовность поделиться им. :)

— Scu11y