| View previous topic :: View next topic |
| Author |
Message |
intorr
n00b
Joined: 17 Mar 2010
Posts: 4
|
 Posted: Wed Mar 17, 2010 6:28 am Post subject: Стабильность Gentoo + SAS1068 + md raid5 или тайна диска sdg |
 |
|
| Code: | server ~ # uname -a
Linux server 2.6.31-gentoo-r10 #1 SMP Mon Mar 15 15:30:23 YEKT 2010 i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux |
| Code: | Manufacturer: ASUSTeK Computer INC.
Product Name: P5BV/SAS
Version: Rev 1.xx
Serial Number: MB-1234567890 |
Собственно история началась давно.
Стоит дома небольшой сервак, инет раздает, да и и работает на нем небольшой пятый рейд.
После очередного обновления ядра (до одного из первых двадцатых ядер) стали в логи периодически (30 мин.) валится сообщения вида:
| Code: | Mar 12 03:30:24 server kernel: sd 4:0:0:0: [sdc] Sense Key : Recovered Error [current]
Mar 12 03:30:24 server kernel: sd 4:0:0:0: [sdc] Add. Sense: ATA pass through information available
Mar 12 03:30:24 server kernel: sd 4:0:1:0: [sdd] Sense Key : Recovered Error [current]
Mar 12 03:30:24 server kernel: sd 4:0:1:0: [sdd] Add. Sense: ATA pass through information available
Mar 12 03:30:24 server kernel: sd 4:0:2:0: [sde] Sense Key : Recovered Error [current]
Mar 12 03:30:24 server kernel: sd 4:0:2:0: [sde] Add. Sense: ATA pass through information available
Mar 12 03:30:25 server kernel: sd 4:0:3:0: [sdf] Sense Key : Recovered Error [current]
Mar 12 03:30:25 server kernel: sd 4:0:3:0: [sdf] Add. Sense: ATA pass through information available
Mar 12 03:30:25 server kernel: sd 4:0:4:0: [sdg] Sense Key : Recovered Error [current]
Mar 12 03:30:25 server kernel: sd 4:0:4:0: [sdg] Add. Sense: ATA pass through information available
Mar 12 03:30:25 server kernel: sd 4:0:4:0: [sdg] Sense Key : Recovered Error [current]
Mar 12 03:30:25 server kernel: sd 4:0:4:0: [sdg] Add. Sense: ATA pass through information available
Mar 12 03:30:25 server ata_id[26537]: HDIO_GET_IDENTITY failed for '/dev/sdg' |
А диски с sdc по sdg подключены к SAS1068.
Ну соответственно google и много в нем копания ни к чему не привели, у многих наблюдалось, но никто ничего толком не накопал ...
Собственные исследования показали, что первые десять строчек появляются когда smartd проверяет состояние дисков. Ручная проверка диском с помощью smartctl приводит к тем же сообщениям.
А последние три строчки - когда udev с помощью ata_id чего-то там делает.
Конечно можно сказать - ну работает же, пусть в логи пишет ...
Но эта история получила продолжение.
Недавно обновил рейд до 1.5Тб винтов (так-же 5 штук). Вначале все работало нормально (месяц - полтора).
А потом началось:
| Code: | Mar 4 23:20:59 server kernel: sd 4:0:0:0: [sdc] Sense Key : Recovered Error [current]
Mar 4 23:20:59 server kernel: sd 4:0:0:0: [sdc] Add. Sense: ATA pass through information available
Mar 4 23:20:59 server kernel: sd 4:0:1:0: [sdd] Sense Key : Recovered Error [current]
Mar 4 23:20:59 server kernel: sd 4:0:1:0: [sdd] Add. Sense: ATA pass through information available
Mar 4 23:20:59 server kernel: sd 4:0:2:0: [sde] Sense Key : Recovered Error [current]
Mar 4 23:20:59 server kernel: sd 4:0:2:0: [sde] Add. Sense: ATA pass through information available
Mar 4 23:20:59 server kernel: sd 4:0:3:0: [sdf] Sense Key : Recovered Error [current]
Mar 4 23:20:59 server kernel: sd 4:0:3:0: [sdf] Add. Sense: ATA pass through information available
Mar 4 23:20:59 server kernel: sd 4:0:4:0: [sdg] Sense Key : Recovered Error [current]
Mar 4 23:20:59 server kernel: sd 4:0:4:0: [sdg] Add. Sense: ATA pass through information available
Mar 4 23:21:31 server kernel: mptscsih: ioc0: attempting task abort! (sc=f5220480)
Mar 4 23:21:31 server kernel: sd 4:0:4:0: [sdg] CDB: ATA command pass through(12)/Blank: a1 08 2e 00 01 00 00 00 00 ec 00 00
Mar 4 23:21:36 server kernel: mptbase: ioc0: LogInfo(0x31140000): Originator={PL}, Code={IO Executed}, SubCode(0x0000)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: task abort: SUCCESS (sc=f5220480)
Mar 4 23:21:36 server kernel: mptbase: ioc0: LogInfo(0x31170000): Originator={PL}, Code={IO Device Missing Delay Retry}, SubCode(0x0000)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: attempting task abort! (sc=f5f08480)
Mar 4 23:21:36 server kernel: sd 4:0:4:0: [sdg] CDB: Read(10): 28 00 71 7b a7 bf 00 01 00 00
Mar 4 23:21:36 server kernel: mptscsih: ioc0: task abort: FAILED (sc=f5f08480)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: attempting task abort! (sc=f691aa80)
Mar 4 23:21:36 server kernel: sd 4:0:4:0: [sdg] CDB: Read(10): 28 00 6e c1 c6 bf 00 00 f8 00
Mar 4 23:21:36 server kernel: mptscsih: ioc0: task abort: FAILED (sc=f691aa80)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: attempting task abort! (sc=d557ec80)
Mar 4 23:21:36 server kernel: sd 4:0:4:0: [sdg] CDB: Read(10): 28 00 70 5a 59 3f 00 00 80 00
Mar 4 23:21:36 server kernel: mptscsih: ioc0: task abort: FAILED (sc=d557ec80)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: attempting target reset! (sc=f5220480)
Mar 4 23:21:36 server kernel: sd 4:0:4:0: [sdg] CDB: ATA command pass through(12)/Blank: a1 08 2e 00 01 00 00 00 00 ec 00 00
Mar 4 23:21:36 server kernel: mptscsih: ioc0: target reset: SUCCESS (sc=f5220480)
Mar 4 23:21:36 server kernel: mptscsih: ioc0: attempting bus reset! (sc=f5220480)
Mar 4 23:21:36 server kernel: sd 4:0:4:0: [sdg] CDB: ATA command pass through(12)/Blank: a1 08 2e 00 01 00 00 00 00 ec 00 00
Mar 4 23:21:37 server kernel: mptscsih: ioc0: bus reset: SUCCESS (sc=f5220480)
Mar 4 23:21:47 server kernel: mptscsih: ioc0: attempting host reset! (sc=f5220480)
Mar 4 23:21:47 server kernel: mptbase: ioc0: Initiating recovery
Mar 4 23:22:00 server kernel: mptscsih: ioc0: host reset: SUCCESS (sc=f5220480)
Mar 4 23:22:10 server kernel: sd 4:0:4:0: Device offlined - not ready after error recovery
Mar 4 23:22:10 server kernel: sd 4:0:4:0: Device offlined - not ready after error recovery
Mar 4 23:22:10 server kernel: sd 4:0:4:0: Device offlined - not ready after error recovery
Mar 4 23:22:10 server kernel: sd 4:0:4:0: Device offlined - not ready after error recovery
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Unhandled error code
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 4 23:22:10 server kernel: end_request: I/O error, dev sdg, sector 1903929279
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Unhandled error code
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 4 23:22:10 server kernel: end_request: I/O error, dev sdg, sector 1858193087
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Unhandled error code
Mar 4 23:22:10 server kernel: sd 4:0:4:0: [sdg] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 4 23:22:10 server kernel: end_request: I/O error, dev sdg, sector 1884969279
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: end_request: I/O error, dev sdg, sector 2930271935
Mar 4 23:22:10 server kernel: md: super_written gets error=-5, uptodate=0
Mar 4 23:22:10 server kernel: raid5: Disk failure on sdg1, disabling device.
Mar 4 23:22:10 server kernel: raid5: Operation continuing on 4 devices.
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server kernel: sd 4:0:4:0: rejecting I/O to offline device
Mar 4 23:22:10 server ata_id[8972]: HDIO_GET_IDENTITY failed for '/dev/sdg'
Mar 4 23:22:10 server kernel: RAID5 conf printout:
Mar 4 23:22:10 server kernel: --- rd:5 wd:4
Mar 4 23:22:10 server kernel: disk 0, o:1, dev:sdd1
Mar 4 23:22:10 server kernel: disk 1, o:1, dev:sdf1
Mar 4 23:22:10 server kernel: disk 2, o:1, dev:sdc1
Mar 4 23:22:10 server kernel: disk 3, o:1, dev:sde1
Mar 4 23:22:10 server kernel: disk 4, o:0, dev:sdg1
Mar 4 23:22:10 server kernel: RAID5 conf printout:
Mar 4 23:22:10 server kernel: --- rd:5 wd:4
Mar 4 23:22:10 server kernel: disk 0, o:1, dev:sdd1
Mar 4 23:22:10 server kernel: disk 1, o:1, dev:sdf1
Mar 4 23:22:10 server kernel: disk 2, o:1, dev:sdc1
Mar 4 23:22:10 server kernel: disk 3, o:1, dev:sde1 |
Первая мысль - один из винтов (sdg) глючный!
Меняю местами винты (соответственно буквы у них меняются), потом еще и кабели менял и в разные разъемы контроллера втыкал (так со всеми винтами делал).
Все остается без изменений - не проходит и десяти дней как sdg вылетает и ТОЛЬКО SDG ...
Т.е. делаем вывод - винты в порядке, кабели в порядке.
SAS контроллер ? Мне кажется тоже в порядке.
Ставим жестокий эксперимент ... оставляем рейд на месяц degraded mode с четырмя дисками.
Рейд работает без проблем. Сбоев не было.
Высказываем гипотезу - SAS контроллер работает без проблем с четырмя дисками. Пятый перетыкаем в встроеный в мать ICH7 контроллер. Ресинкаем рейд и ждем ... Часов через пять sdg вылетает из рейда.
И тут замечаем одну строчку в логах:
| Code: | | Mar 4 23:22:10 server ata_id[8972]: HDIO_GET_IDENTITY failed for '/dev/sdg' |
Время появления этого сообщения ВСЕГДА ДО СЕКУНДЫ СОВПАДАЕТ с временем сбоя диска.
Высказываем гипотезу - udev вместе с ata_id творят там что-то нехорошее, либо драйвер (который CONFIG_FUSION_SAS) сбоит (но если так, то почему всегда эта строчка есть ???)
Собственно теперь вопросы к тем из сообщества, кто дочитал до конца:
1). Кто-нибудь с таким встречался ?
2). Если встречался то решил ли, или докопался до чего-нибудь ?
3). Есть ли идеи из-за чего это именно с sdg ?
4). Почему udev делает запрос (использует ata_id) HDIO_GET_IDENTITY, хотя это как я понял только для ata дисков, а здесь по сути scsi и, как я понял, udev должен использовать scsi_id для этого (по-крайней мере если руками scsi_id запускать, то он выдает инфу о диске, а ata_id только ошибку) ? |
|
| Back to top |
|
 |
fank
l33t
Joined: 16 Oct 2004
Posts: 794
Location: Minsk, Belarus
|
| Posted: Wed Mar 17, 2010 3:40 pm Post subject: |
|
|
у меня есть только одно логическое объяснение, или, вернее, скорее подозрение
в драйвере для контроллера используется временная заглушка HDIO_GET_IDENTITY
или же, udev еще ничего не знает про идентификатор устройства для такого контроллера
в любом из этих случаев наилучшим решением будет копипаст сего подробного репорта на местный багтрекер
_________________
Слово „христианство“ основано на недоразумении; в сущности, был один христианин, и тот умер на кресте. |
|
| Back to top |
|
|
intorr
n00b
Joined: 17 Mar 2010
Posts: 4
|
| Posted: Mon Mar 22, 2010 5:30 am Post subject: |
|
|
| fank wrote: | у меня есть только одно логическое объяснение, или, вернее, скорее подозрение
в драйвере для контроллера используется временная заглушка HDIO_GET_IDENTITY
или же, udev еще ничего не знает про идентификатор устройства для такого контроллера |
Я порылся в исходниках Fusion-MPT, udev и smartmontools.
Похоже Fusion-MPT вобще не поддерживает запрос HDIO_GET_IDENTITY.
А udev и smartmontools как раз его и используют. Точнее вначале его, а потом, когда он возвращает ошибку, используют другой, а он как раз исполняется нормально.
Я пока для udev нашел временное решение, в файле /lib/udev/rules.d/60-persistent-storage.rules закомментировал строчку:
| Code: | | KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="ATA", IMPORT{program}="ata_id --export $tempnode" |
Теперь udev ко всем SATA устройствам относится как к SCSI. И использует для их идентификации не ata_id, а scsi_id.
А smartd пока просто отключил. Посмотрим как рейд будет себя вести.
| fank wrote: | | в любом из этих случаев наилучшим решением будет копипаст сего подробного репорта на местный багтрекер |
С английским у меня плохо, врятли я сумею это нормально описать. |
|
| Back to top |
|
|
intorr
n00b
Joined: 17 Mar 2010
Posts: 4
|
| Posted: Sat Apr 03, 2010 2:50 pm Post subject: |
|
|
Прошло две недели, рейд ведет себя абсолютно стабильно.
Подожду ка я еще две недели. |
|
| Back to top |
|
|
intorr
n00b
Joined: 17 Mar 2010
Posts: 4
|
| Posted: Fri Apr 23, 2010 6:13 pm Post subject: |
|
|
Собственно говоря, пошло больше месяца.
Рейд за это время вел себя абсолютно стабильно.
А значит мое предположение оказалось верным. Теперь можно начать думать из-за чего, почему и как сделать чтобы все работало ... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Russian
