Comments 11
Правильно ли я понял, что отключение-включение нужно после каждой неудачи чтения битого блока, что приводит к тому, что данные могут вычитываться очень долго? Как вариант 14 суток чтение заняло в вашем случае
Почему бы просто не использовать #PERST ? Посмотрел спеку на всякий случай, потому что не всегда все сигналы испльзуются, в данном случае сброс вроде у всех поддерживается
Правильно ли я понял, что отключение-включение нужно после каждой
неудачи чтения битого блока, что приводит к тому, что данные могут
вычитываться очень долго?
Долго это ждать пока ddrescue поймет что не читается. Опция --timeout=0 не помогает.
А передергивание по питанию быстро происходит. Тут проблема в том что передернуть не дожидаясь ddrescue можно, но тогда в map файле этот сектор как битый не будет отмечен и позиция не поменяется.
Почему бы просто не использовать #PERST ?
А как именно его использовать ?
Линукс делает reset но это не помогает. Возможно какой то другой reset.
sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 6:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 00 89 1c 00 00 01 00 00
scsi host6: uas_eh_device_reset_handler start
usb 4-3: reset SuperSpeed Gen 1 USB device number 108 using xhci_hcd
scsi host6: uas_eh_device_reset_handler success
sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
sd 6:0:0:0: [sdd] tag#5 CDB: Test Unit Ready 00 00 00 00 00 00
scsi host6: uas_eh_device_reset_handler start
usb 4-3: reset SuperSpeed Gen 1 USB device number 108 using xhci_hcd
scsi host6: uas_eh_device_reset_handler success
sd 6:0:0:0: Device offlined - not ready after error recovery
sd 6:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=41s sd 6:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 00 89 1c 00 00 01 00 00
blk_update_request: I/O error, dev sdd, sector 8985600 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0Можете сфоткать что на том выводе сейчас висит? Можно глянуть мультиметром есть ли сброс на том выводе когда Линукс как вы говорите его сбрасывает. Хотя лучше осциллом, если там импульс
Похоже Линукс сбрасывает чип адаптера, а сам чип может и не дёргает perst
Самое простое туда подать ноль самому и проверить сработает ли это также как и питанием подвергать. Но надо глянуть что там сейчас на выводе. Возможно просто подтяжка, а самого управления нет, а может есть. Просто может сброс быстрее будет отрабатываться чем питанием дергать. Тогда и время можно сократить будет.
Сфотографировал. Слишком мелкие контакты. Щупами туда лезть я не буду.
Фото
По сути для ускорения процесса копирования, даже если удастся как то задействовать PERST#, и это сработает - это ничего не даст. Так как большую часть времени занимает ожидание обработки ошибки прошивкой SSD, ядром Linux и процессом ddrescue
В плане софта возможно еще есть потенциал куда дорабатывать.
Единственное правильное решение это расковырять прошивку SSD и отключить контроль ошибок. Но это решение не универсальное.
А без этого JMicron-адаптера, напрямую в PCIe слоте как оно себя ведёт? В таком виде должно быть куда больше возможностей настройки, к примеру, можно попробовать уменьшить /sys/module/nvme_core/parameters/io_timeout, да и reset какой-нибудь там же поискать (временно нахожусь вдали от машин с NVMe, не на чем посмотреть подробнее).
Именно эти диски не проверял. Так как их прислали отдельно от моноблоков где они стояли.
Но другие вели себя так: после ошибки пропадает из системы и до отключения включения компа не работает.
Вот например такой Kingston RBUSNS8154P3128GJ3 Выдавал в dmesg вот это. И после этого ничего не сделать до отключения включения всего ноутбука.
nvme nvme0: I/O 773 QID 4 timeout, aborting
nvme nvme0: I/O 0 QID 0 timeout, reset controller
То есть нужно тогда делать аппаратное отключение питания для M.2 слота. Можно наверно через какой нибудь райзер сделать. Но из за глюков по шине PCI-E комп может вообще зависнуть. Некоторые SSD вешали систему.
Можно просто удалять PCIe девайс и делать рескан, диск под новым номером проявится.
Это проще делается в BSD, диск проще в BSD копируется (т.к. утилита камконтрол удобнее). Однако в Линуксе это тоже возможно. Что помогает уменьшить потребление сломанного диска, это позволяет уменьшить скорость и копировать медленно, другой вариант через USB.
Чаще всего у диска проблема с полной шиной (Привет Кингстон), если у кингстона срезать скорость даже на один уровень (с 4гигабайт до 300мегабайт) то он работает более менее стабильно на копирование. Другой вариант впаять его в PCIe3 контроллер, тоже будет работать.
Можно просто удалять PCIe девайс и делать рескан, диск под новым номером проявится.
Это не работает для неисправных дисков. Сегодня еще раз проверил. Затем комп вообще зависает.
Вот вчера принесли комп HP с SSD M.2 NVMe Kioxia. На бэдах отваливается, при этом пропадает содержимое /sys/class/nvme* и даже выгрузка и повторная подгрузка модулей nvme nvme_core не помогает. Но при этом комп продолжает работать (кроме nvme подсистемы), а не зависает намертво как с Kimtigo.
При этом при подключении через USB3 мост обрабатывает ошибку и читает дальше.
Скрины
Чаще всего у диска проблема с полной шиной (Привет Кингстон)
Не встречал такого. Все ссд и SATA и PCI-E отваливались строго на определенных секторах. Если попытаться прочитать именно битый сектор - сразу отвалится. То есть дело в том что прошивка диска зависает вместо обработки ошибки.
Проверил. Вставил в M.2. Один из этих Kimtigo.
Загрузил Linux с флешки. Запустил dmesg -Wt и ddrescue
Сначала ddrescue зависла. В dmesg одно сообщение
nvme nvme1: I/O 385 QID 2 timeout, aborting
Через минуту завис комп полностью.
Думаю что бесперспективно пытаться через PCI-E глючные SSD читать.
Удобней ориентироваться не на /dev/sdX, а на что-то типа /dev/disk/by-id, оно стабильно привязано к данному накопителю.
Можно. Но для надежного перезапуска ddrescue в цикле это не подходит. Так как неисправные HDD/SSD могут в процессе подглючивания при пере-подключении в очередной раз определиться как другая модель и с другим SN. И соответственно путь в /dev/disk/by-id тоже изменится.
Поэтому реализовал в скрипте другой метод. Для SATA устройств - номер порта. Для USB - ID VID:PID
Восстановление данных с M.2 NVMe SSD. Скрипт ddrescue-loop v0.2