> А с этим живут по таким причинам:

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

> - Без ECC-оперативки данные всё равно могут побиться в памяти.

На практике btrfs при таком обычно орет "csum error" в логи и если юзерь не совсем баклан... из того что на виду, отловился глючный проц и пару плашек оперативки как раз. Неплохой валидатор работы оборудования получился.

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

> - Диски жёсткие и твердотельные имеют ECC. Его хватает, чтобы сказать "тут
> bad block", а не молча вернуть прочитанный из нужного места мусор.

Это может себе вообразить только тот кто никогда не интересовался как это работает и видимо не имеет особого опыта эксплуатации компьютерных систем.

Во первых что там сделает немеряный фирмвароблоб - целиком на его усмотрение. Реакция фирмвар на подобные вещи весьма разнообразна.
Во вторых FEC может с некоей (небольшой, но не нулевой) вероятностью посчитать рандомную труху за что-то валилдное. Это редко, но с ростом плотности устройств, числа секторов и погоней за емкостью и ценой за счет общей хлипкости...

Поэтому на практике я видал как девайсы выгружают из секторов явный левак, не удосужившись сообщить IO error. И у тех додиков на такой случай плана нет. У многих райдов, кстати, тоже. Btrfs то при наличии чексум - вопит csum failed, БЕРЕТ БЛОК С ДРУГОЙ КОПИИ (точно зная что хочет и какой там чексум), чинит битую копию, заодно и кривой сектор ремапнуть получится. Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать, спасибо если не вбив девайс в failsafe mode, после чего юзер уж точно к датареку пойдет. И один сектор, который фирмвари ремапнуть раз плюнуть, может эскалировать в убер-проблему, фатальную и дорогую. Потому что сами вы уже оттуда ничего не вытащите скорее всего.

> Использовать софтовый data checksumming - значит не доверять end-to-end protection внутри
> диска (если он есть) или заменять его, расширять его на остальные
> звенья (SATA-контроллер).

Это как раз отличная идея, чисто с точки зрения теорвера. Если вероятность лажи чексумы ФС 1/N и девайса 1/M то вероятность что они ОБЕ одновременно лажанут - уже 1/(N*M) что куда как прикольнее. А девайсы выгружающие треш в секторах без репортов IO Error я лично видел. Btrfs то на это вопит csum failed и чинит, чего б ему не.

У меня даже есть пара особо сыпучих флех - посмотреть, проиграю я когда теорверу с схемой DUP на заведомо хреновом носителе или нет :). Реально - на сыпучей флехе становится можно таскать файлы ценой ополовинивания емкости, таки не мрет по простому.

> ошибок и недоработок в прошивке, вызывающих в том числе phantom writes,
> misdirected reads/writes.

Де факто это end to end проверка работы железа. И это очень хорошо. Дада, и 1 глючный шнурок тоже под внимание попал за "csum failed". А какой-нибудь ext4 тихо схарчил бы такие пакости.

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

Если вместо того чтобы умничать на форумах сходить качнуть лекции CS где расписаны типовые алгоритмы и их свойства, можно узнать что чудес не бывает и есть некая вероятность что алгоритм примет труху за чистую монету. И чексум может сойтись на левых данных. Конкретика конечно зависит от деталей, типа ширины чексумы. FEC вообще не чексум, он в этом качестве "до кучи" подрабатывает и имеет довольно компромиссные свойства, но не тратить же места еще и на чексумы, убавив емкость на лэйбе девайса?! Отдел маркетинга вас не поймет.

> и молчаливое возвращение прочитанного мусора...

Я пару раз даже на HDD такое видел, а для флешастых девайсов это "довольно типовой" faulure mode я б сказал. И статистика конечно же набралась потому что я знакомым btrfs нарекламил. Ну мы вместе и узнали о свойствах оборудования. И о чем не пишет отдел маркетинга.

> сбылся их прогноз о дисках, которые сложно прочитать целиком без единой
> ошибки (12+ ТБ, URE=10^-14), халат отняли.

На самом деле для небольших инсталяхах IMHO RAID5 можно и попытаться. Но только понимая ограничения этого всего. Вообще делать большие или пролвинутые сетапы совсем не понимая тематику - чревато.

> Другие халат не снимают, потому что у них ext4/XFS или винда без
> ReFS или макось. И работает. И тихое повреждение данных кажется слишком
> мифологизированным.

Я паре таких мифологов потом с их NTFSа выколупывал добро. Когда винды в бсод при маунте нтфс начинают улетать - так то да, даже жирафу заметно что гамно какое-то :). В этом месте линуксоид под боком срубает свой EPIC WIN. Хотя-бы за счет альтернативного парсера который в синий скрин ну вот не уходит.

> Мол, data checksumming необходим там, где обитают хранилки с 520/528
> байтами на сектор, но не везде.

Я btrfs в довольно большом числе довольно разных сетапов юзаю, от SD и eMMC до нескольких многодисковых штук (RAID1 в основном) и ну вот не считаю чексумы чем-то лишним.

> Ты халат надел, а базу данных и виртуалки допустил положить в nodatacow.

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

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

Ну как бы если кому плевать на свои данные я так то не против, но когда они при этом начинают высовываться и что-то про (не)надежность ФС лечить - это не находит моего понимания.

> Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности
> при чтении (а не только при ручном запуске проверки).

Ну а вот BTRFS заметив сбой чексумы берет из второй копии и чинит. Выглядит как-то так:

[82374.200674] BTRFS info (device sdg): scrub: started on devid 1
[82471.511063] BTRFS error (device sdg): fixed up error at logical 3180593152 on dev /dev/sdg physical 5336465408
[82491.759994] BTRFS error (device sdg): fixed up error at logical 2634088448 on dev /dev/sdg physical 5863702528

Это катитт и с DUP на 1 девайсе, и с RAID1 на разных. Не обязательно scrub пинать, обычное чтение тоже котируется. Это я для иллюстрации как сие работает на заведомо-сыпучей флехе scrub пнул чтобы увидеть сбой чексум и его парирование за обозримое время.

> Как я понимаю, эта же проблема будет в btrfs+nodatacow и её не
> будет* с dm-integrity, о котором писал ниже.

Никто не заставляет юзать nodatacow. Сценарии разные бывают. У меня даже местами виртуалки с btrfs на btrfs норм живут. Не то чтобы это рекомендуется для нагруженных сценариев, но если понимать лимиты технологий, с ними можно жить.

> * защита от misdirected reads/writes должна требовать дополнительной настройки.

К сожалению во всем этом мусоре - нормальный менеджмент не завезли. В btrfs DUP на однодевайсном конфиге 1 командой делается. Прозрачно. На ходу. Без дестроя. Теперь донавесьте 2 копии на 1 девайсе с авто-фиксом факапов вашим способом. Ну или почем мой ноут или те выводки одноплатников не могут попытаться парировать единичный бэд, например? У меня вот могут - и это оказалось полезным улучшением свойств файлух как по мне.

> твоих слов про "не general purpose", достанут очередной свежий баг в
> btrfs и станут размахивать им: https://bugzilla.redhat.com/show_bug.cgi?id=2169947.

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

Но говоря за себя - в моих конфигах это просто работает. Какие-то проблемы я огребал только с -rc ядрами, заодно узнав что brtfs'ники очень крутые, компетентные и оперативные ребята которые горой за качество своей вундервафли. Сообща оттрекали и загасили все что мешало мне жить. Опенсорс - это вот так. А желаюшие быть консумерами и получить ынтырпрайз грейд экспериенс именно его и получат. И пусть потом не плакают, а хотя-бы и занося чемодан денег или выписывая баги в какое там спортлото.

> Чем холоднее данные, тем больше вариантов открывается, вплоть до par2.

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

> Так речь о хотелках по новым ФС, как некоторые фичи накостыливаются-наслаивается к
> старым ФС - понятно. Дарю убийственный аргумент: "нечего тут на опеннете
> рассуждать, иди и сделай свою правильную ФС, делом займись".

А таки разработчики ФС зачастую открыты к разумным пожеланиям. Особенно если они не сильно сложно натягиваются на эннфй дизайн. А иногла даже и сложно. Ну вон в zfs 10 лет поотмазывались но все же смогли сову, на глобус, тьфу, рефлинки то-есть на "типа cow". Позор ситуации в том что XFS который изначально не cow и то раньше это смог. Думаю прозрачно намекает почему Кент копипастил с btrfs дизайн, а не с того нечто. Оно ж даже экстенты полноценные не умеет и затыкает тормоз-дизайн гигазами оперативы.

>> А у вас на такой случай какой хитрый план?
> Если он рутинно вылез, то диск сам о нём скажет,

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

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

Btrfs в случае IO error сразу идет за другой копией и чинит из нее. И какая разница по csum failed это инициировано или по io error. На результат не влияет.

> По-хорошему, все сетапы надо проверить через внедрение ошибок.

У меня есть даже небольшая коллекция особо мерзеньких девайсов. В основном благодаря btrfs и его чексумам. Вот заодно и посмотрю как штука Кента отнесется к этому самому. Мне ж не нужна сферическая файлуха для идеального вакуума.

> Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?),
> zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup.

И пусть себе есть. Где-то там. Попользовавшись btrfs я для себя решил что хочу видеть системный менеджмент вот так. Просто, логично, прозрачно, с динамическим перераспределением ресурсов под задачи и возможностью реконфигурации малой кровью.

А те долбаные этажерки - пусть их похи всякие используют, вместе с другими экспертами. И очень круто что господа типа Кента понимают где такому менеджменту систем вообще и ФС в частности на самом деле место. На помойке! И скучать по всему этому брейнфаку мало кто будет, имхо. А интеграция ФС и девайсов дает нефиговые новые возможности, которое вон то либо не может, либо реализует так что лучше б и не позорилось. Типа какихнить снапшотов в LVM. Нахрен мне такие снапшоты после того как я btrfs попробовал. И у Кента они по идее должны быть не хуже. Но это еще предстоит проверить.