> Это вы совсем не знаете работы современных носителей.

Напротив, я более-менее представляю что по факту есть в секторе и как реально устроены сектора накопителя.

> Слышали о таком понятии как низкое форматирование? Во-о-о-от. А оно есть. В
> начале 90-х делалось вручную, теперь нет. Нет даже упоминаний.

Теперь служебная разметка наносится прямо на заводе - так называемые сервометки. По ним накопитель понимает что происходит и где спозиционирована голова. Дело в том что в современных накопителях используется линейное перемещение голов при помощи "voice coil". Отклонение катушки пропорцинально напряжению на ней. У головы нет дискретных шагов. По этому поводу накопитель не может работать без сервометок. И не может их сам пересоздать, как минимум без посторонней помощи. Сервометки используются для понимания текущей позиции головы и в какую сторону напряжение на катушке менять дальше чтобы голова попала в нужное место накопителя. Ну а если нет сервометок - неизвестно где голова. Вот потому и нет процедуры низкоуровневого формата. Его слет == накопитель в мусорку. Сам он такую разметку просто так уже не пересоздаст.

> Контроллер делает до 32 попыток (теперь даже эта цифра х/з и может менятся)

В секторах современных накопителей есть не чексум а ECC, который может не только обнаруживать ошибки но и исправлять, если их не очень много. В SMART кстати бывают параметры отражающие статистику по этому делу. И, кстати, 4K сектора стали использовать в том числе и потому что там можно ECC поудачнее раскинуть. С 512 байтовым сектором ECC занимает бОльший процент поверхности чем с 4096-байтовым сектором.

Сколько именно попыток накопитель сделает - очень зависит от, это целиком на совести его фирмвары и весьма. Никакого стандарта на это нет. И например RAID-ориентирванные накопители не долбятся до упора. Иначе есть шанс что контроллер выкинет диск по таймауту операции. А еще бывает что ECC исправил ошибку - при этом сектор может быть помечен как нестабильный, но данные с него успешно достанут.

> бэд с переносом сектора в резервную область.

А это вообще в меру дури фирмвари накопителя и ее настроек. Опять же - никакого стандарта на жто нет. Внутреннее дело накопителя.

> ФС узнаёт о бэдах чуть ли не в последнюю очередь.

Тем не менее, если был битый сектор и его не удалось прочитать даже с ECC - очень большой вопрос что там и кому вернет накопитель как результат чтения. Может быть, I/O error, что логично. Может "что прочлось". Кто там писал фирмвару и насколько они криворукие - никто не знает. К тому же есть еще глюки контроллеров, повреждения данных при передаче от накопителя, etc. Там конечно нынче тоже контрольные суммы бывают, но достаточно слабые. И при большом объеме данных вполне можно нарваться на ситуацию когда таки пролезут какие-то невалидные данные.

> Это первое, второе — бэды не имеют отношения к поднятому вопросу контроля
> целосности данных. Сюрприз?

Лишний уровень который имеет шансы поймать лажу предыдущих уровней - само по себе достаточно здраво.

> Ну тогда посмотрите что предоставляет по этому поводу zfs. Посмотрели? Ни-и-иче-е-его.

Она умеет чексуммирование данных. Как и btrfs. При наличии избыточности на RAID это может позволить обнаружить верную копию и работать с ней. Ну а если избыточности нет - ФС сможет только констатировать облом, что логично.

> Для zfs бэды вообще не существуют.

Для нее существуют чексуммы, которые она таки проверяет. Btrfs тоже такие фичи имеет. А вот ext4 - и подобные - ну да, им до балды что там с данными творится. Собственно, журналинг только метаданных давно узаконил такое состояние дел.