> Это вы совсем не знаете работы современных носителей.Напротив, я более-менее представляю что по факту есть в секторе и как реально устроены сектора накопителя.
> Слышали о таком понятии как низкое форматирование? Во-о-о-от. А оно есть. В
> начале 90-х делалось вручную, теперь нет. Нет даже упоминаний.
Теперь служебная разметка наносится прямо на заводе - так называемые сервометки. По ним накопитель понимает что происходит и где спозиционирована голова. Дело в том что в современных накопителях используется линейное перемещение голов при помощи "voice coil". Отклонение катушки пропорцинально напряжению на ней. У головы нет дискретных шагов. По этому поводу накопитель не может работать без сервометок. И не может их сам пересоздать, как минимум без посторонней помощи. Сервометки используются для понимания текущей позиции головы и в какую сторону напряжение на катушке менять дальше чтобы голова попала в нужное место накопителя. Ну а если нет сервометок - неизвестно где голова. Вот потому и нет процедуры низкоуровневого формата. Его слет == накопитель в мусорку. Сам он такую разметку просто так уже не пересоздаст.
> Контроллер делает до 32 попыток (теперь даже эта цифра х/з и может менятся)
В секторах современных накопителей есть не чексум а ECC, который может не только обнаруживать ошибки но и исправлять, если их не очень много. В SMART кстати бывают параметры отражающие статистику по этому делу. И, кстати, 4K сектора стали использовать в том числе и потому что там можно ECC поудачнее раскинуть. С 512 байтовым сектором ECC занимает бОльший процент поверхности чем с 4096-байтовым сектором.
Сколько именно попыток накопитель сделает - очень зависит от, это целиком на совести его фирмвары и весьма. Никакого стандарта на это нет. И например RAID-ориентирванные накопители не долбятся до упора. Иначе есть шанс что контроллер выкинет диск по таймауту операции. А еще бывает что ECC исправил ошибку - при этом сектор может быть помечен как нестабильный, но данные с него успешно достанут.
> бэд с переносом сектора в резервную область.
А это вообще в меру дури фирмвари накопителя и ее настроек. Опять же - никакого стандарта на жто нет. Внутреннее дело накопителя.
> ФС узнаёт о бэдах чуть ли не в последнюю очередь.
Тем не менее, если был битый сектор и его не удалось прочитать даже с ECC - очень большой вопрос что там и кому вернет накопитель как результат чтения. Может быть, I/O error, что логично. Может "что прочлось". Кто там писал фирмвару и насколько они криворукие - никто не знает. К тому же есть еще глюки контроллеров, повреждения данных при передаче от накопителя, etc. Там конечно нынче тоже контрольные суммы бывают, но достаточно слабые. И при большом объеме данных вполне можно нарваться на ситуацию когда таки пролезут какие-то невалидные данные.
> Это первое, второе — бэды не имеют отношения к поднятому вопросу контроля
> целосности данных. Сюрприз?
Лишний уровень который имеет шансы поймать лажу предыдущих уровней - само по себе достаточно здраво.
> Ну тогда посмотрите что предоставляет по этому поводу zfs. Посмотрели? Ни-и-иче-е-его.
Она умеет чексуммирование данных. Как и btrfs. При наличии избыточности на RAID это может позволить обнаружить верную копию и работать с ней. Ну а если избыточности нет - ФС сможет только констатировать облом, что логично.
> Для zfs бэды вообще не существуют.
Для нее существуют чексуммы, которые она таки проверяет. Btrfs тоже такие фичи имеет. А вот ext4 - и подобные - ну да, им до балды что там с данными творится. Собственно, журналинг только метаданных давно узаконил такое состояние дел.
