# Стабильность Gentoo + SAS1068 + md raid5 или тайна диска sdg

## intorr

```
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
```

```
Manufacturer: ASUSTeK Computer INC.

Product Name: P5BV/SAS

Version: Rev 1.xx

Serial Number: MB-1234567890
```

Собственно история началась давно.

Стоит дома небольшой сервак, инет раздает, да и и работает на нем небольшой пятый рейд.

После очередного обновления ядра (до одного из первых двадцатых ядер) стали в логи периодически (30 мин.) валится сообщения вида:

```
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 штук). Вначале все работало нормально (месяц - полтора).

А потом началось:

```
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 вылетает из рейда.

И тут замечаем одну строчку в логах:

```
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 только ошибку) ?

----------

## fank

у меня есть только одно логическое объяснение, или, вернее, скорее подозрение

в драйвере для контроллера используется временная заглушка HDIO_GET_IDENTITY

или же, udev еще ничего не знает про идентификатор устройства для такого контроллера

в любом из этих случаев наилучшим решением будет копипаст сего подробного репорта на местный багтрекер

----------

## intorr

 *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 закомментировал строчку:

```
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:*   

> в любом из этих случаев наилучшим решением будет копипаст сего подробного репорта на местный багтрекер

 

С английским у меня плохо, врятли я сумею это нормально описать.

----------

## intorr

Прошло две недели, рейд ведет себя абсолютно стабильно.

Подожду ка я еще две недели.

----------

## intorr

Собственно говоря, пошло больше месяца.

Рейд за это время вел себя абсолютно стабильно.

А значит мое предположение оказалось верным. Теперь можно начать думать из-за чего, почему и как сделать чтобы все работало ...

----------

