?

Log in

No account? Create an account

Евгений Музыченко

Previous Entry Share Next Entry
Стандартные виндовые средства не нашли ошибок на дефектном диске
emuzychenko
Образовался у меня 320-гиговый HDD с энным количеством (около 1%) нечитаемых и неписанных неописуемых незаписываемых секторов. Решил пометить дефекты средствами NTFS и пустить диск под малоценную всячину. Теперь сижу и охреневаю - что в семерке, что в последней десятке, ни гуевый форматтер, ни гуевый проверяльщик, ни chkdsk с ключом /b (который, судя по утверждениям MS, должен делать именно это) не нашли на диске ни единой ошибки. По их мнению, он не имеет проблем, и полностью пригоден для использования.

Кому интересно, подробности здесь.

  • 1
Я тебе даже расскажу почему никто этого не делает: если ремапов много, то в 99% случаях это говорит о том, что нужно выкашивать уже целиком физические треки, о которых внешняя часть контроллера просто и не подозревает. А ещё, это, как правило, говорит о том, что полётные характеристики нарушены, так что головы запросто могут цеплять соседние треки.

В общем, при нынешней плотности записи уже просто ненулевое количество ремапов -- повод вывести диск из эксплуатации. даже для хранения не-единственной копии бэкапов.

Это все понятно, я уже о другом - какого лешего все виндовые проверялки в "максимальных" режимах проверки дружно рапортуют, что ошибок на диске нет?

А держать на диске предполагалось детские мультики и сериалы, которые, если и пропадут, то будет только лучше. :)

у меня есть подозрение.

раньше, пока маппинг был один-в-один, оно что-то ещё могло.

а потом перестало, в результате:
- новую функциональность писать дорого;
- выносить старое нельзя
- а как нормальные люди в документации написать "this option has been left for backward compatibility, and currently does nothing" не позволяет гордость Кровавого Ынтырпрайза™ ;-P

Э-э-э, ты о чем? :) Тот же chkdsk/b должен, как в древнейшие времена, тупо прочитать каждый кластер. Прочитался - оставить, как есть (свободным/занятым), не прочитался - пометить, как дефектный. Ему вообще не положено знать про какой-то там маппинг и прочую физическую организацию. :)

Судя по времени выполнения на пустом диске (10-15 минут с /b против нескольких секунд без него), он таки делает что-то дополнительно к обычной проверке, но я не понимаю, что именно. Я в сообщении на RSDN отмечал, что в ходе процесса "проверки" сколько-нибудь активного дискового обмена нет ни у chkdsk, ни у других процессов.

Ну и называть "средствами проверки накопителя" средства, которые не находят ни одного дефекта из сотен тысяч, как-то не совсем правильно, согласись? :)

я не знаю, почему оно делает вид что что-то делает (время выполнения да, дисковая активность нет -- я правильно понял?)

и не считаю что это правильно

я просто предположил развитие бызнес-процесса, которое могло привести к такому результату ;)

Там вообще хитро: тулзы показывают прогресс, диск потрескивает, дисковых обменов не видно. Такое впечатление, что они используют какие-то низкоуровневые средства верификации вместо банального чтения.

Я согласен, что развитие бизнес процесса могло бы привести просто к исключению всех этих средств проверки, с заменой их на запросы к SMART: типа, если какие-то атрибуты поехали вниз - начинать ругаться на испорченный накопитель и требовать его замены.

Но зачем (а главное - как) они сделали то, что я у себя наблюдаю - непонятно. :)

Разве современные диски самостоятельно не делают remaps плохих участков? Ну, то есть, вот это вот всё. Как только железка начинает это делать ценность chkdsk /R теряется ввиду того, что железка начинает сама подсовывать живое вместо мёртвого. Я так это понимаю, по крайней мере, и предполагаю, что о состоянии диска нужно судить по его самодиагностике и тому сколько он сам себе ошибок насобирал, прежде чем их масштаб становится таким, что они переливаются через край и уже операционная система начинает их замечать.

Ну вот я и имею ситуацию, когда железка какое-то время делала ремапы, затем резервы кончились, и она начала тупо давать ошибки. А все виндовые "проверялки" упорно твердят мне, что диск не имеет ошибок, хотя любой посекторный сканер эти ошибки обнаруживает, и попытки читать (до форматирования) или писать (после форматирования) файлы также приводят к ошибкам.

Я именно об этом, если что.

Ключ /b - это, скорее, наоборот.

https://superuser.com/questions/693400/how-to-unmark-an-ntfs-cluster-as-bad/994420

А такой путь, как локализовать сбойные секторы через partition table, рассматривался? Или эти секторы по всей поверхности рассыпаны?

По документации MS, нужен именно /b:

/b NTFS only: Clears the list of bad clusters on the volume and rescans all allocated and free clusters for errors. /b includes the functionality of /r. Use this parameter after imaging a volume to a new hard disk drive.

Сосредоточены они довольно компактно, но возиться с группировкой и оформлением в раздел мне уже лень.

  • 1