> Теоретические измышлизмы это прекрасно. А вон то - смотрение как это на
> практике работало. Это было надежнее чем выслушивать опеннетных экспертов, и я
> по факту видел - вон то. О чем и спел.

Верну контекст: после отсеивания изначально проблемной памяти можно жить и примерно одинаково страдать от единичных космических лучей что с btrfs, что без btrfs. Тут теорвер btrfs не поможет, единичное повреждение в non-ECC RAM скорее всего заденет не его данные.

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

Но они очевидны, дождаться первых проблем и: память - memtest, SATA-кабель - проверка 0xC7 CRC Error Count в SMART'е, процессор и чипсет - страдать, менять всё с запасом. Ну и организационный момент, конечно - пассивное ожидание kernel panic более фатально, ожидание настроенного уведомления о плохом SMART'е и проблемном scrub'е менее фатально. Если хочется ещё раз провозгласить, что это менее удобно, то я опережу: "это менее удобно".

> В них допущение что диск мрет катастрофично и сразу. По мере роста
> плотности и скоростей, усугубленных желанием юзерей все и сразу и за
> копейки, это стало все менее похоже на правду.

Всё-таки там допущение, что диск сообщит об ошибке, не обязательно своей смертью. Не такое уж плохое допущение, ибо скоростей на HDD и так нет, надёжность требуется и юзверям, унификация корпоративных и домашних HDD есть, рост плотности в 10^9 раз за историю HDD остальным аспектам надёжности заметным образом не повредил, поэтому пусть и обнаружению ошибок не повредит. С SSD хуже, да, но там как минимум Samsung'у надо оправдывать ожидания (на 3dnews тихим повреждением отличились Silicon Motion и Phison) и - пожелание в /dev/null - тихое повреждение на SSD не должно становиться нормой.

> Если я вижу кейсы где это срабатывает и чинит, своими глазами, о чем вы тут вещаете?

О здравом смысле. При высокой частоте тихих ошибок классические RAID-массивы стали бы бесполезными, даже до домохозяек доносили бы мысль через анекдот "печатаю 1200 ударов в минуту, но такая ерунда получается" и они бы смутно помнили, что QNAP почему-то нельзя покупать*.

А раз классические RAID-массивы не бесполезны, то ECC обычно хватает и лишний пафос не нужен, чтобы сказать "да, такие делают, в них есть не-ко-то-рый смысл, но я рекомендовать не могу". Оговорки о пользе контрольных сумм были ("из нужного места" => исключение misdirected read/writes, "вызывающих в том числе misdirected read/writes"), а всё хочется видеть, будто я говорю об их бесполезности.

И у нас разговор в одном русле идёт:
- Есть жизнь и без btrfs/ZFS
- Да разве это жизнь!?
- Живём как-то.
- Да вы не знаете, что такое жизнь!
- Но мы живы, вот это вот device mapper, тут par2, а это...
- Вы существуете.

* Why does QNAP NAS not use the Btrfs file system? https://www.qnap.com/solution/qnap-ext4/en/

> А что до категоричности - если я смотрю...

Да-да, то есть нет. Лучше так:
- Вы таки утверждаете, что ECC на диске всегда хватает для обнаружения ошибки?
- Не всегда, да и проблема не ограничивается miscorrection'ами.

> > Ну так не спорю. Только подтверждаю, что не видел такого.
> Вероятность этого заисит от числа инстансов btrfs...

Аргхм, не видел другого - реализаций RAID, жертвующих скоростью ради чтения всех зеркал/чётности и сверки при каждом обращении к данным. Вот FUSE на основе Рида-Соломона видел, а такое не видел.