[Из песочницы] Как не надо восстанавливать данные, или чтобы вам тоже так везло
Все мы периодически сталкиваемся с отказами устройств хранения. В интернете написаны сотни инструкций, как без специального оборудования прочитать все что только возможно с устройств, еще отвечающих на обычные запросы ОС. Но мне долгие годы не везло, диски либо умирали совсем-совсем, либо файловая система была еще доступна и я просто читал все то, что читалось в обычном режиме. И ждал. Должно же было случиться, чтобы умирающий диск попал мне именно в состоянии, требующем большего, чем самые элементарные действия?
И вот этот день настал. На разделе поверх софтового raid0, хранившем, откровенно говоря, всякую ерунду, файлы оказались недоступны, а причина — долгожданный I/O Error. Неожиданным было то, что устройства-носителя второй половинки рэйда вообще не оказалось в выводе fdisk, хотя список файлов был доступен. Перезагрузка — и массив собрался, а файлы прекрасно читаются. В отчете SMART видно огромное количество переназначенных секторов. Как раз то, что нужно. Отключаю диски и начинаю продумывать стратегию восстановления.
Для вычитывания уцелевших секторов решено было использовать GNU ddrescue — специализированную версию dd для чтения данных с умирающих дисков, которая позволяет выбирать стратегию чтения и умеет строить карту диска для продолжения работы после сбоев, а они обязательно будут, работаю ведь с неисправными устройством.
Итак, подключаю первый диск к своему десктопу, и POST торжественно сообщает, что один из подключенных дисков совсем плох. Загрузка ОС прошла штатно, если не считать пару сообщений о каких-то ошибках ata устройства. После успешной загрузки fdisk -l пациента видит, ну наконец-то я буду восстанавливать целостность данных raid0.
ddrescue -ndAvv /dev/sdd1 bad mapbad
Процесс пошел довольно резво, 80 МБ/с. Из-за шума охлаждающего диски вентилятора, изъятого специально по такому случаю из списанного сервера, леденящих кровь звуков чтения умирающего диска было бы не слышно, даже если бы они были. Возможно, не слышать их даже лучше. Меньше знаешь — крепче спишь.
К утру работа ddrescue завершилась, и на новеньком диске лежали образ и карта погибающего товарища. Но повторный запуск ddrescue почему-то завершался подозрительно быстро, а карта
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue -ndAvv /dev/sdd1 bad mapbad
# Start time: 2016-02-12 09:05:07
# Current time: 2016-02-12 09:06:45
# Finished
# current_pos current_status
0xAA7A800000 +
# pos size status
0x00000000 0xA6FF000000 +
0xA6FF000000 0x00810000 -
0xA6FF810000 0x0D7F0000 +
0xA70D000000 0x00810000 -
0xA70D810000 0x2887F0000 +
0xA996000000 0x01020000 -
0xA997020000 0x147E0000 +
0xA9AB800000 0x00810000 -
0xA9AC010000 0x4D7F0000 +
0xA9F9800000 0x00810000 -
0xA9FA010000 0x7AFF0000 +
0xAA75000000 0x01840000 -
0xAA76840000 0x03FC0000 +
0xAA7A800000 0x42E258400 -
«Что-то очевидно пошло не так», — подсказал сонный внутренний голос. «А попробуй-ка fdisk -l» — вот, и разум уже подключился. /dev/sdd в выводе не оказалось. — Как такое вообще возможно?, — Ах да, на сервере было тоже самое, — Значит, не все еще пропало: примерно такие мысли обитали в голове весь рабочий день.
Вечером подопытный диск опять подавал признаки жизни, а передо мной стояла непростая задача: что делать с полученным образом, ведь ddrescue c финализированной картой что-либо читать отказывался, оставив мне файл образа меньше размера раздела.
С одной стороны, ddrescue умеет заполнять - блоки произвольными данными, чтобы потом определить битые файлы. С другой стороны, я не просил его делать спарс-файл (параметр -S), и усиленное гугление вопроса о том, как именно будет заполняться меньший-чем-раздел файл образа, осталось без ответа.
На самом деле нужно было внимательно прочитать инструкцию и найти в ней параметр -p, который резервирует место на диске перед созданием обычного файла.
Полагаться на случай крайне не хотелось, и я решил с калькулятором в руках изучить карту диска. Оказалось, что 96% содержимого диска успешно прочиталось и попало в первый + блок. Но к сожалению, сумма всех + блоков не давала размер считанного образа, что окончательно спутало мне все карты. По-этому я пошел другим путем: раз у меня есть хорошее начало и черт знает что в конце, почему бы не достать старый добрый dd и не слепить из непонятного образа как раз то, с чем можно спокойно работать?
dd if=bad of=bad_new bs=16M count=42751
dd if=/dev/zero of=bad_new bs=1024 seek=700432384 count=32139617
Результат — новенький образ, который теперь в точности такого же размера, как и умирающий раздел, а именно 750153729024 байт. Теперь займемся ноликами в конце. Делаю вручную
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue -ndAvv /dev/sdd1 bad mapbad
# Start time: 2016-02-12 09:05:07
# Current time: 2016-02-12 09:06:45
# Finished
# current_pos current_status
0xA6FF810000 ?
# pos size status
0x00000000 0xA6FF000000 +
0xA6FF000000 0x00810000 -
0xA6FF810000 0x0D7F0000 ?
0xA70D000000 0x00810000 -
0xA70D810000 0x2887F0000 ?
0xA996000000 0x01020000 -
0xA997020000 0x147E0000 ?
0xA9AB800000 0x00810000 -
0xA9AC010000 0x4D7F0000 ?
0xA9F9800000 0x00810000 -
0xA9FA010000 0x7AFF0000 ?
0xAA75000000 0x01840000 -
0xAA76840000 0x03FC0000 ?
0xAA7A800000 0x42E258400 -
и запускаю:
ddrescue -ndAvv /dev/sdd1 bad_new mapbad
Ура! Теперь все хорошо. Читающиеся блоки с диска переехали на пустое место нового образа по нужным адресам, а карта опять финализировалась, и мои приключения подходят к концу. Но может быть сделать последний рывок и перечитать - блоки по одному сектору? Теперь даю ddrescue
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue -ndAvv /dev/sdd1 bad mapbad
# Start time: 2016-02-12 09:05:07
# Current time: 2016-02-12 09:06:45
# Finished
# current_pos current_status
0xA6FF000000 ?
# pos size status
0x00000000 0xA6FF000000 +
0xA6FF000000 0x00810000 ?
0xA6FF810000 0x0D7F0000 +
0xA70D000000 0x00810000 ?
0xA70D810000 0x2887F0000 +
0xA996000000 0x01020000 ?
0xA997020000 0x147E0000 +
0xA9AB800000 0x00810000 ?
0xA9AC010000 0x4D7F0000 +
0xA9F9800000 0x00810000 ?
0xA9FA010000 0x7AFF0000 +
0xAA75000000 0x01840000 ?
0xAA76840000 0x03FC0000 +
0xAA7A800000 0x42E258400 ?
и запускаю так:
ddrescue -ndAvv /dev/sdd1 -с1 bad_new mapbad
В общем, он повел себя совсем не так, как я рассчитывал. Наткнувшись на плохой сектор в - блоке, он переходил к следующему - блоку, пока не зацепился за уверенное чтение из последнего - блока. Час спустя я остановил это безобразие с помощью CTRL-C и запустил чтение на нормальной скорости. Еще несколько гигабайт из конца раздела прочитались, пока ddrescue снова не напоролся на сбойные сектора, что почему-то опять привело к пропаданию /dev/sdd из системы и финализации карты, которая сильно распухла и представляла собой месиво из +, - и ? блоков. Разбирать все это не было уже никакого смысла, и я решил прекратить мучить умирающего и заняться, наконец, сборкой массива. Но перед этим захотелось выяснить, что было бы, если бы я использовал режим заполнения. Готовлю заполнитель и включаю режим заполнения, не забыв заменить карту на первоначальную:
printf "BADSECTOR" > tmpfile
ddrescue --fill-mode=- tmpfile bad mapbad
И получаю еще один образ правильного размера! Как он это сделал для меня осталось загадкой, ведь я несколько раз пересчитал сумму размеров + блоков из карты, и она не совпадала с размером готового файла.
И вот на месте отдающего магнитную душу богу уже его здоровый собрат, а я выполняю команды:
losetup /dev/loop1 bad_new
mdadm --assemble -o /dev/md12 /dev/loop1 /dev/sdd1
Но результат, мягко говоря, не тот, что я ожидал после 24 часов надежды на успех:
mdadm: no RAID superblock on /dev/loop1
mdadm: /dev/loop1 has no superblock - assembly aborted
Что делать, попробуем теперь пообщаться с гуглом и разделами:
#mdadm --examine /dev/loop1
mdadm: No md superblock detected on /dev/loop1.
— То есть как это no md superblock detected?
— А у этого, который пока здоров?
#mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 0.90.00
UUID : 64d38efd:b8e92c8c:f5292846:21864477
Creation Time : Fri Oct 10 20:22:23 2008
Raid Level : raid0
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Update Time : Fri Oct 10 20:22:23 2008
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Checksum : 6f768a67 - correct
Events : 1
Chunk Size : 4K
— Версия 0.90.00? А где должен быть суперблок у mdadm 0.90.00?
— В конце раздела.
— А как его прочитать с помощью mdadm?
— Никак.
— То есть как это никак? Ну ладно, так где там он поточнее?
— Не дальше 128K, но не ближе 64К от конца раздела, выровнен по границе 64К, размер 4К.
Н-да, беру dd и проверяю:
dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd if=last128 of=bad_new bs=1024 seek=732571873 count=128
Да, суперблок записался в конец раздела по правильному адресу, но собираться массив с двумя одинаковыми суперблоками все равно не хочет, значит надо дать ему именно тот суперблок, с помирающего.
Снова замена диска, только бы прочитался:
#dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd: reading `/dev/sdd1': Input/output error
0+0 records in
0+0 records out
«Да, такого удара Великий комбинатор не испытывал никогда», — почему-то в памяти всплыла именно эта бессмертная цитата.
Ну ладно, так легко мы не сдаемся. А мы вот так:
dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror
Эх, размер last128 >0, но
dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror,sync
От целой части убираем один блок, это и будет адрес начала суперблока 11446436×64*1024=750153629696
Приводим адрес к блоку 4К: 750153629696/(1024×4)=183142976 и выполняем
dd if=/dev/sdd1 of=superblock bs=4k skip=183142976 count=1
Вот они, последние 128К. Прописываю их в конец образа, перезагружаюсь со здоровым диском, и массив собрался!
Осталась простая команда и:
#mount -o ro /dev/md11 /srv/old/
mount: wrong fs type, bad option, bad superblock on /dev/md11,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Ну вот это уже как-то совсем обидно. Последний раз на сервере массив собирался и ext3 монтировалась. Вывод dumpe2fs подозрений не вызывает, статус раздела clean, адреса альтернативных суперблоков видны, но с ними почему-то тоже не монтируется. Надо бы ее полечить, но в таком виде и с половиной данных без бэкапа лечить нельзя. Эх, придется перекинуть еще полтора терабайта. Конечно, по-хорошему надо бы сделать образ с теперь уже условно рабочего диска с помощью ddrescue, но все это уже сильно надоело и поэтому делаю так:
dd if=/dev/md11 of=ext3 bs=16M conv=noerror,sync
И спать, а наутро пробую:
losetup /dev/loop2 ext3
mount -o ro /dev/loop2 /srv/old/
И оно монтируется! Структура каталогов на первый взгляд не изменилась, а файлы, от которых у меня есть хэши, прочитались без ошибок. На восстановленном разделе свободно всего 20 ГБ, поэтому его loop-файл получил заслуженный атрибут:
chattr +i ext3
и запись в fstab:
/srv/ext3 /srv/old ext3 ro,loop 0 0
В качестве заключения дочитавшему до сюда рекомендую:
- настроить автоматическое резервное копирование важных и не очень данных,
- периодически просматривать отчеты SMART,
- использовать для восстановления устройство USB to SATA, или аналогичное для вашего диска,
- относиться к любому диску, с которого нужно снять образ, как к умирающему и использовать GNU ddrescue,
- помнить, что если дело дойдет до восстановления действительно важных данных, то такого везения точно не будет.
Feb 11 23:25:08 vlad kernel: [ 1.966762] ata4.00: configured for UDMA/133
Feb 11 23:25:08 vlad kernel: [ 1.967027] scsi 3:0:0:0: Direct-Access ATA ST3750640AS D PQ: 0 ANSI: 5
Feb 11 23:25:08 vlad kernel: [ 1.999957] sd 3:0:0:0: Attached scsi generic sg3 type 0
Feb 11 23:25:08 vlad kernel: [ 1.999959] sd 3:0:0:0: [sdd] 1465149168 512-byte logical blocks: (750 GB/699 GiB)
Feb 11 23:25:08 vlad kernel: [ 1.999975] sd 3:0:0:0: [sdd] Write Protect is off
Feb 11 23:25:08 vlad kernel: [ 1.999977] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Feb 11 23:25:08 vlad kernel: [ 2.000004] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 11 23:25:08 vlad kernel: [ 2.014841] sdd: sdd1
Feb 11 23:25:08 vlad kernel: [ 2.014974] sd 3:0:0:0: [sdd] Attached SCSI removable diskFeb 11 23:25:08 vlad kernel: [ 6.668531] ata4.00: exception Emask 0x0 SAct 0x20 SErr 0x0 action 0x0
Feb 11 23:25:08 vlad kernel: [ 6.668577] ata4.00: irq_stat 0x40000008
Feb 11 23:25:08 vlad kernel: [ 6.668604] ata4.00: failed command: READ FPDMA QUEUED
Feb 11 23:25:08 vlad kernel: [ 6.668638] ata4.00: cmd 60/08:28:b0:66:54/00:00:57:00:00/40 tag 5 ncq 4096 in
Feb 11 23:25:08 vlad kernel: [ 6.668638] res 51/40:08:b0:66:54/00:00:57:00:00/00 Emask 0x409 (media error) Feb 11 23:25:08 vlad kernel: [ 6.668673] ata4.00: status: { DRDY ERR }
Feb 11 23:25:08 vlad kernel: [ 6.668685] ata4.00: error: { UNC }
Feb 11 23:25:08 vlad kernel: [ 6.756422] ata4.00: configured for UDMA/133
Feb 11 23:25:08 vlad kernel: [ 6.756438] sd 3:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 11 23:25:08 vlad kernel: [ 6.756443] sd 3:0:0:0: [sdd] tag#5 Sense Key : Medium Error [current] [descriptor]
Feb 11 23:25:08 vlad kernel: [ 6.756447] sd 3:0:0:0: [sdd] tag#5 Add. Sense: Unrecovered read error - auto reallocate failed
Feb 11 23:25:08 vlad kernel: [ 6.756451] sd 3:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 57 54 66 b0 00 00 08 00
Feb 11 23:25:08 vlad kernel: [ 6.756454] blk_update_request: I/O error, dev sdd, sector 1465149104
Feb 11 23:25:08 vlad kernel: [ 6.756504] ata4: EH complete
Feb 11 23:25:08 vlad kernel: [ 10.446467] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Feb 11 23:25:08 vlad kernel: [ 10.446510] ata4.00: irq_stat 0x40000008
Feb 11 23:25:08 vlad kernel: [ 10.446537] ata4.00: failed command: READ FPDMA QUEUED
Feb 11 23:25:08 vlad kernel: [ 10.446570] ata4.00: cmd 60/08:00:b0:66:54/00:00:57:00:00/40 tag 0 ncq 4096 in
Feb 11 23:25:08 vlad kernel: [ 10.446570] res 51/40:08:b0:66:54/00:00:57:00:00/00 Emask 0x409 (media error) Feb 11 23:25:08 vlad kernel: [ 10.446606] ata4.00: status: { DRDY ERR }
Feb 11 23:25:08 vlad kernel: [ 10.446617] ata4.00: error: { UNC }
Feb 11 23:25:08 vlad kernel: [ 10.554902] ata4.00: configured for UDMA/133
Feb 11 23:25:08 vlad kernel: [ 10.554915] sd 3:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 11 23:25:08 vlad kernel: [ 10.554920] sd 3:0:0:0: [sdd] tag#0 Sense Key : Medium Error [current] [descriptor]
Feb 11 23:25:08 vlad kernel: [ 10.554923] sd 3:0:0:0: [sdd] tag#0 Add. Sense: Unrecovered read error - auto reallocate failed
Feb 11 23:25:08 vlad kernel: [ 10.554926] sd 3:0:0:0: [sdd] tag#0 CDB: Read(10) 28 00 57 54 66 b0 00 00 08 00
Feb 11 23:25:08 vlad kernel: [ 10.554929] blk_update_request: I/O error, dev sdd, sector 1465149104
Feb 11 23:25:08 vlad kernel: [ 10.554971] Buffer I/O error on dev sdd, logical block 183143638, async page read
Feb 11 23:25:08 vlad kernel: [ 10.555011] ata4: EH complete
Feb 11 23:25:08 vlad kernel: [ 10.641458] md: bindFeb 11 23:25:08 vlad kernel: [ 10.653880] md: linear personality registered for level -1
Feb 11 23:25:08 vlad kernel: [ 10.655703] md: multipath personality registered for level -4
Feb 11 23:25:08 vlad kernel: [ 10.659291] md: raid1 personality registered for level 1
Feb 12 03:41:06 vlad kernel: [15370.712691] ata4.00: status: { DRDY ERR }
Feb 12 03:41:06 vlad kernel: [15370.712693] ata4.00: error: { UNC }
Feb 12 03:41:06 vlad kernel: [15370.808463] ata4.00: configured for UDMA/133
Feb 12 03:41:06 vlad kernel: [15370.808501] sd 3:0:0:0: [sdd] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 12 03:41:06 vlad kernel: [15370.808505] sd 3:0:0:0: [sdd] tag#4 Sense Key : Medium Error [current] [descriptor]
Feb 12 03:41:06 vlad kernel: [15370.808509] sd 3:0:0:0: [sdd] tag#4 Add. Sense: Unrecovered read error - auto reallocate failed
Feb 12 03:41:06 vlad kernel: [15370.808513] sd 3:0:0:0: [sdd] tag#4 CDB: Read(10) 28 00 55 3b 11 3f 00 08 00 00
Feb 12 03:41:06 vlad kernel: [15370.808515] blk_update_request: I/O error, dev sdd, sector 1429935476
Feb 12 03:41:06 vlad kernel: [15370.808529] ata4: EH complete
Feb 12 03:41:39 vlad kernel: [15403.451737] ata4.00: exception Emask 0x0 SAct 0x7e SErr 0x0 action 0x6 frozen
Feb 12 03:41:39 vlad kernel: [15403.451745] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451751] ata4.00: cmd 60/50:08:3f:68:3d/05:00:55:00:00/40 tag 1 ncq 696320 in
Feb 12 03:41:39 vlad kernel: [15403.451751] res 40/00:48:29:02:3b/00:00:55:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451754] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451756] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451762] ata4.00: cmd 60/b0:10:8f:6d:3d/02:00:55:00:00/40 tag 2 ncq 352256 in
Feb 12 03:41:39 vlad kernel: [15403.451762] res 40/00:b8:ac:06:3b/00:00:55:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451764] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451766] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451771] ata4.00: cmd 60/50:18:3f:70:3d/05:00:55:00:00/40 tag 3 ncq 696320 in
Feb 12 03:41:39 vlad kernel: [15403.451771] res 40/00:00:84:09:3b/00:00:55:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451774] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451776] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451781] ata4.00: cmd 60/b0:20:8f:75:3d/02:00:55:00:00/40 tag 4 ncq 352256 in
Feb 12 03:41:39 vlad kernel: [15403.451781] res 40/00:00:74:15:3b/00:00:55:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451783] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451785] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451790] ata4.00: cmd 60/18:28:3f:78:3d/07:00:55:00:00/40 tag 5 ncq 929792 in
Feb 12 03:41:39 vlad kernel: [15403.451790] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451793] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451795] ata4.00: failed command: READ FPDMA QUEUED
Feb 12 03:41:39 vlad kernel: [15403.451800] ata4.00: cmd 60/e8:30:57:7f:3d/00:00:55:00:00/40 tag 6 ncq 118784 in
Feb 12 03:41:39 vlad kernel: [15403.451800] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 12 03:41:39 vlad kernel: [15403.451802] ata4.00: status: { DRDY }
Feb 12 03:41:39 vlad kernel: [15403.451807] ata4: hard resetting link
Feb 12 03:41:44 vlad kernel: [15408.799827] ata4: link is slow to respond, please be patient (ready=0)
Feb 12 03:41:49 vlad kernel: [15413.463949] ata4: COMRESET failed (errno=-16)
Feb 12 03:41:49 vlad kernel: [15413.463958] ata4: hard resetting link
Feb 12 03:41:54 vlad kernel: [15418.816093] ata4: link is slow to respond, please be patient (ready=0)
Feb 12 03:41:59 vlad kernel: [15423.476229] ata4: COMRESET failed (errno=-16)
Feb 12 03:41:59 vlad kernel: [15423.476238] ata4: hard resetting link
Feb 12 03:42:04 vlad kernel: [15428.840370] ata4: link is slow to respond, please be patient (ready=0)
Feb 12 03:42:34 vlad kernel: [15458.509128] ata4: COMRESET failed (errno=-16)
Feb 12 03:42:34 vlad kernel: [15458.509137] ata4: limiting SATA link speed to 1.5 Gbps
Feb 12 03:42:34 vlad kernel: [15458.509139] ata4: hard resetting link
Feb 12 03:42:39 vlad kernel: [15463.525279] ata4: COMRESET failed (errno=-16)
Feb 12 03:42:39 vlad kernel: [15463.525288] ata4: reset failed, giving up
Feb 12 03:42:39 vlad kernel: [15463.525291] ata4.00: disabled
Feb 12 03:42:39 vlad kernel: [15463.525313] ata4.00: device reported invalid CHS sector 0
Feb 12 03:42:39 vlad kernel: [15463.525316] ata4.00: device reported invalid CHS sector 0
Feb 12 03:42:39 vlad kernel: [15463.525328] ata4: EH complete
Feb 12 03:42:39 vlad kernel: [15463.525358] sd 3:0:0:0: [sdd] tag#1 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525363] sd 3:0:0:0: [sdd] tag#1 CDB: Read(10) 28 00 55 3d 68 3f 00 05 50 00
Feb 12 03:42:39 vlad kernel: [15463.525366] blk_update_request: I/O error, dev sdd, sector 1430087743
Feb 12 03:42:39 vlad kernel: [15463.525378] sd 3:0:0:0: [sdd] tag#2 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525381] sd 3:0:0:0: [sdd] tag#2 CDB: Read(10) 28 00 55 3d 6d 8f 00 02 b0 00
Feb 12 03:42:39 vlad kernel: [15463.525383] blk_update_request: I/O error, dev sdd, sector 1430089103
Feb 12 03:42:39 vlad kernel: [15463.525394] sd 3:0:0:0: [sdd] tag#3 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525397] sd 3:0:0:0: [sdd] tag#3 CDB: Read(10) 28 00 55 3d 70 3f 00 05 50 00
Feb 12 03:42:39 vlad kernel: [15463.525399] blk_update_request: I/O error, dev sdd, sector 1430089791
Feb 12 03:42:39 vlad kernel: [15463.525407] sd 3:0:0:0: [sdd] tag#4 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525410] sd 3:0:0:0: [sdd] tag#4 CDB: Read(10) 28 00 55 3d 75 8f 00 02 b0 00
Feb 12 03:42:39 vlad kernel: [15463.525412] blk_update_request: I/O error, dev sdd, sector 1430091151
Feb 12 03:42:39 vlad kernel: [15463.525422] sd 3:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525425] sd 3:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 55 3d 78 3f 00 07 18 00
Feb 12 03:42:39 vlad kernel: [15463.525426] blk_update_request: I/O error, dev sdd, sector 1430091839
Feb 12 03:42:39 vlad kernel: [15463.525434] sd 3:0:0:0: [sdd] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.525436] sd 3:0:0:0: [sdd] tag#6 CDB: Read(10) 28 00 55 3d 7f 57 00 00 e8 00
Feb 12 03:42:39 vlad kernel: [15463.525438] blk_update_request: I/O error, dev sdd, sector 1430093655
Feb 12 03:42:39 vlad kernel: [15463.526601] sd 3:0:0:0: [sdd] tag#8 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.526607] sd 3:0:0:0: [sdd] tag#8 CDB: Read(10) 28 00 55 3d 80 bf 00 05 48 00
Feb 12 03:42:39 vlad kernel: [15463.526610] blk_update_request: I/O error, dev sdd, sector 1430094015
Feb 12 03:42:39 vlad kernel: [15463.526623] sd 3:0:0:0: [sdd] tag#9 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.526626] sd 3:0:0:0: [sdd] tag#9 CDB: Read(10) 28 00 55 3d 86 07 00 02 b8 00
Feb 12 03:42:39 vlad kernel: [15463.526628] blk_update_request: I/O error, dev sdd, sector 1430095367
Feb 12 03:42:39 vlad kernel: [15463.526644] sd 3:0:0:0: [sdd] tag#10 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.526647] sd 3:0:0:0: [sdd] tag#10 CDB: Read(10) 28 00 55 3d 88 bf 00 08 00 00
Feb 12 03:42:39 vlad kernel: [15463.526649] blk_update_request: I/O error, dev sdd, sector 1430096063
Feb 12 03:42:39 vlad kernel: [15463.526666] sd 3:0:0:0: [sdd] tag#11 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 12 03:42:39 vlad kernel: [15463.526669] sd 3:0:0:0: [sdd] tag#11 CDB: Read(10) 28 00 55 3d 90 bf 00 08 00 00
Feb 12 03:42:39 vlad kernel: [15463.526670] blk_update_request: I/O error, dev sdd, sector 1430098111
Feb 12 09:04:52 vlad kernel: [34796.610216] blk_update_request: 29908 callbacks suppressed
Feb 12 09:04:52 vlad kernel: [34796.610221] blk_update_request: I/O error, dev sdd, sector 1400864832
Feb 12 09:04:52 vlad kernel: [34796.610231] blk_update_request: I/O error, dev sdd, sector 1400866176
Feb 12 09:04:52 vlad kernel: [34796.610240] blk_update_request: I/O error, dev sdd, sector 1400866880
Feb 12 09:04:52 vlad kernel: [34796.610249] blk_update_request: I/O error, dev sdd, sector 1400868928
Feb 12 09:04:52 vlad kernel: [34796.610258] blk_update_request: I/O error, dev sdd, sector 1400870976
Feb 12 09:04:52 vlad kernel: [34796.610268] blk_update_request: I/O error, dev sdd, sector 1400873024
Feb 12 09:04:52 vlad kernel: [34796.610277] blk_update_request: I/O error, dev sdd, sector 1400875072
Feb 12 09:04:52 vlad kernel: [34796.610286] blk_update_request: I/O error, dev sdd, sector 1400877120
Feb 12 09:04:52 vlad kernel: [34796.610295] blk_update_request: I/O error, dev sdd, sector 1400879168
Feb 12 09:04:52 vlad kernel: [34796.610301] blk_update_request: I/O error, dev sdd, sector 1400880512
