Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 16 Sep 24 17:28:15, всего сообщений: 10763
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 2188 из 10763 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           15 Oct 14 21:40:11
Кому : Alex Korchmar                                       15 Oct 14 21:40:11
Тема : Re: Какие есть грабли с SSD?
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+15a81acd
На   : area://RU.UNIX.BSD?msgid=ddt.demos.su+46c7c166
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=<1187496333@ddt.demos.su>+194b40db
==============================================================================
15 окт 2014, среда, в 12:41 NOVT, Alex Korchmar написал(а):

EG>> Два раза. И поправка, это был не gmirror, а graid, у которого
EG>> есть kern.geom.raid.disconnect_on_failure=1 по дефолту и
EG>> kern.geom.raid.start_timeout и kern.geom.raid.read_err_thresh
AK> ну, это чуть лучше - в плане того что оно радикально затупит один раз,
AK> и после этого резко потеряет интерес к поврежденному диску.
AK> Hо, боюсь, это через часик произойдет. Когда драйвер таки соизволит вернуть
AK> read_err хотя бы единожды.
EG>> То есть, Мотин решал.
AK> оно с другого конца должно решаться - с низкоуровневых драйверов, которые
AK> в любой сложной ситуации должны на современном железе сразу сообщать наверх
AK> о проблеме, не тупя часами в ожидании ответа (подозреваю, любой рейд и любая
AK> fs написанные не в позапрошлом веке, такую ситуацию обработают лучше).
AK> Боюсь, что никто всерьез этим не занимается - те кто могли бы, давно
AK> понакупили себе hba за миллион. Или вообще давно уже живут на SAN за миллиард.

Вот сегодня, как по заказу:

Oct 15 14:02:10 rao kernel: (ada0:ata2:0:0:0): WRITE_DMA. ACB: ca 00 80 94 0d 40 00 00 00 00 40 00
Oct 15 14:02:10 rao kernel: (ada0:ata2:0:0:0): CAM status: ATA Status Error
Oct 15 14:02:10 rao kernel: (ada0:ata2:0:0:0): ATA status: 61 (DRDY DF ERR), error: 04 (ABRT )
Oct 15 14:02:10 rao kernel: (ada0:ata2:0:0:0): RES: 61 04 91 94 0d 00 00 00 00 01 00
Oct 15 14:02:10 rao kernel: (ada0:ata2:0:0:0): Retrying command
... куча ретраев ...
Oct 15 14:02:10 rao kernel: : Synchronization request failed (error=5).(ada0:ata2:0:0:0): WRITE_DMA. ACB: ca 00 00 95 0d 40 00 00 00 00 40 00
...
Oct 15 14:02:10 rao kernel: GEOM_MIRROR: Device gm0: provider ada0 disconnected.(ada0:ata2:0:0:0): WRITE_DMA. ACB: ca 00 00 95 0d 40 00 00 00 00 40 00
...
Oct 15 14:02:10 rao kernel: GEOM_MIRROR: Device gm0: rebuilding provider ada0 stopped.(ada0:ata2:0:0:0): WRITE_DMA. ACB: ca 00 40 95 0d 40 00 00 00 00 40 00
...
Oct 15 14:02:41 rao kernel: ada0 at ata2 bus 0 scbus0 target 0 lun 0
Oct 15 14:02:41 rao kernel: ada0: <WDC WD2500JS-00NCB1 10.02E02> s/n WD-WCANKK248113 detached
Oct 15 14:03:11 rao kernel: (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 31 59 1c 40 1d 00 00 00 04 00
Oct 15 14:03:11 rao kernel: (ada0:ata2:0:0:0): CAM status: Command timeout
Oct 15 14:03:11 rao kernel: (ada0:ata2:0:0:0): Error 5, Periph was invalidated
Oct 15 14:03:11 rao kernel: (ada0:ata2:0:0:0): Periph destroyed

После чего /dev/ada0 вообще исчез из системы.
Контроллер atapci1: <ServerWorks HT1000 SATA150 controller>

В итоге оказалось, что на диске уже 750 плохих блоков и вообще
он про себя кричит SMART FAIL. О чём smartd в логи ругался
ещё раньше :-)

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

Eugene
--- slrn/1.0.1 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.103732 секунды