Поэтому я сделал то, что сказала мне моя интуиция: я попытался переписать только крошечную нечитаемую область с помощью этой команды ddrescue (это можно сделать с помощью более простого инструмента dd, но я менее знаком с ним):
lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log [Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.] И это сработало: в качестве проверки я повторно создал первый ГБ, и на этот раз ошибки не было (я пробовал эту частичную обработку изображений перед запуском вышеуказанной команды, и тогда область ошибок все еще была там, с точно таким же местоположением и размером Я также заметил, что он был пропущен сразу же, без замедления, в отличие от того, что обычно происходит, когда есть реальный «физический» плохой сектор, и он замедляется или зависает на несколько секунд перед пропуском); «короткая самопроверка» теперь завершается без ошибок.
До этого я пробовал некоторые инструменты Windows: сканирование на чтение с Hard Disk Sentinel заставляло его зависать на неопределенное время, мне приходилось выключать диск; аналогично, попытка получить доступ к проблемной области с помощью WinHex заставила его зависнуть, пока диск не был выключен.
Итак, я прав, что это был случай «логических» поврежденных секторов, и что диск физически исправен и безопасен для повторного использования, так как в SMART ни разу не отображался «ожидающий» или «перераспределенный» сектор процесса? Какова вероятная причина этого, возможно, операция записи, прерванная неправильным завершением работы? Является ли это распространенной проблемой, и обычно ли это делает диск неработоспособным, когда он влияет на системный файл?