> пока не будет поводов - не буду, нахрена мне ненужные проверки?

Это как pkunzip.zip - без чексум ты это не заметишь и будешь уверен что все ЗБС. Но на современных объемах данных и скоростях магия количеств серьезно нагибает теорвер vs "read error rate".

> Я не верю в ваши мифы и легенды про самомодифицирующиеся байтики на дисках.

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

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

Поэтому онлайновый scrub с фоновым приоритетом и имеет некое право на жизнь. И таки я видел случаи когда он таки реально репайрил единичные сбои. Бывает. Хоть и весьма редко на нормальном железе. Заодно самодиагностикой подрабатывает.

> Обычный fsck а не какие-то проверки ненужного ненужно "по всей площади".

Одно другое не заменяет. И вон то актуально например в многодисковой конфиге чтобы не обнаружить тот бэд когда перестройка вылетевшего совсем диска пирспичила.

> опыт.

А мой опыт вот - видал несколько бэдов заруленых btrfs'ом по именно той механике. И?

> а у меня не орет. Видно, что-то делаю неправильно.

Зависит от железа, количества инстансов оного и много чего еще. В норме он конечно орать и не должен. Но случаи бывают разные. И вот раз в дохрена лет даже на ноуте случайный бэд вылез. Ну как вылез так и аннулировался. Btrfs починил данные, винч ремапнул сектор при очередной записи, и оно и дальше работало себе долго и счастливо. Так намного лучше имхо.

> А вот виснуть и портить данные - да, умеет.

В моих конфигах, вот, не виснет. А если попробует - быренько познакомится с дебагером. Если конечно это не про тормозной отклик винчей при налете на бэды, таймаут на это через команды SCT рулится, это причина их появления если что. А у некоторых серий "для RAID" оно даже активно по дефолту.

> либо повиснет, перезагрузится ресетом и убьет даже те данные которые ничем не
> виноваты, просто под руку попали. Велкам ту рил волд Нео, жри
> хрючево - осетрина твоя была воображаемой.

У меня таких страстей почему-то не бывает. Толи баги меня боятся, знают что ядебагер достану, толи я идиотских действий типа out of tree модулей рушаших память и плохо тестированых не гоняю, но вон то в моих конфигах не характерно.

> ты как обычно в состоянии рассказывать сказочки своего локалхоста или вовсе чтение
> викивракии. Про sct он прочитал, ох б-жечки ж мой (а ничего
> что в доступных тебе дисках нет никакого sct десять лет как?

Вообще-то набор команд SCT поддерживался практически всеми более-менее новыми дисками которые я видел (да, я любопытный и тыкаю палочкой в девайсы). А нет его либо в антиках либо в твердотельных где он нахрен не вперся, там и retry сильно быстрее и много попыток смысла делать меньше.

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

Знание как сделать чтобы ни...я не работало - еще менее полезное. Почему-то :). Хотя если тебя к конкурентам засылать - то, конечно, ЗБС.