> Эмм, в оперативную память кладут и другие вещи, помимо данных для btrfs
> scrub. И они побьются заодно.

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

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

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

> Случай с глючной оперативкой (которую можно выявить и иначе) достаточно
> очевиден, а халат нужен в разговоре про космически-лучевые soft error'ы.

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

> Поведай, зачем тогда изобрели RAID-массивы. В них (без доп. data checksumming'а) не
> было бы смысла, если бы диск обычно умирал "тихо".

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

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

> Хотя и так ясно, что изобретатели не интересовались, как это работает и не
> имели особого опыта.

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

> На этом держатся все системы без контрольных сумм для данных (без T10-PI,
> ZFS, btrfs, ReFS, dm-integrity што там ещё).

Они так то довольно специфично держатся. Редко но метко караптя данные - и поскольку чексум нет, как вы это узнаете то если оно изредка? А, ну вот когда что-то осыпется - тогда и :). Только опять же - а откуда вы узнаете кто вас подвел, DMA переписавший что-то в раме или хард вернувший труху? Опосля - уже не видно.

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

> Слова я выбирал, категоричности избегал, дальше мысль раскрыл, исключения описал.

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

А что до категоричности - если я смотрю на явление своими глазами и мне тут кто-то лечит что не, это не проблема - я несколько не ОК с этим. Если теория не описывает картинку которую я вижу, это хреновая теория, которая должна быть списана в утиль. Тут нет места для компромисса. Теория или стыкуется с практикой, или нет. Для нестыковки хватит 1 конкретного примера. Который я и привел. Вполне себе девайс выдающий левак без IO error. Мой тестовый кролик теперь, ибо весьма подленькая штука отловленная случайно.

>> Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать
> Но что сможет сделать btrfs без избыточности?

Он так то метаданные по дефолту DUP раскладывает на 1-дисковых конфигах. Вот как раз из соображений выживаемости и датарекавери. Для данных это ессно надо мануально врубать потому что ополовинит место на девайсе и скорость записи. Но в ряде конфиг с этим можно жить. А сделать аналог этой фичи как-то еще - ну не то что совсем нельзя, но такой гимор и side effects что этим никто заниматься не будет. А тут 1 команду вбить и готово.

> ext4-без-массива-под-ней здесь всё-таки как соломенное чучело для спора.

А с массивом под ней - соломенное чучело переезжает в менеджмент всей этой пакости. Кода все сложно, хреново, не гибко, плохо поддается динамической реконфигурации. А узнать что именно /dev/sdf выгрузил труху даже не изволив в IO error - да удачи.

А чтоб еще это прозрачно парировать в фоне без моего участия...  хм, у меня на основе этой технологии выводки одноплатников, допустим, есть. А вы хоть раз в жизни такой сетап собирали вообще, чтобы рассказать мне как это на практике работать будет?

> Можно и патенты Hynix с его miscorrection metric'ами и miscorrection threshold'ами.

Лекции CS полезнее - там алгоритмы как они есть, без приукрас. С честной оценкой свойств. А производителей флеша - более одного, технологий тоже.

Вон то наблюдение чисто статистическое, я есть в некоторых местах где юзеры с упомянутой траблой иногда рисуются. И у меня есть несколько сыпучек ведущих себя вот именно так. Btrfs пополнил мою коллекцию странной фигни.

> Перестараться - это, наверное, некорректное упрощение, но всё-таки у SSD есть возможности
> следить за своим здоровьем, свалиться в fail-safe пораньше.

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

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

Я лично на такие приколы натыкался. Этого достаточно чтобы считать failure mode имеющим место быть. Раскидать btrfs там и тут очень способствовало обнаружению подобных сюрпризов. А как вы это без чексум по простому отловите, интересно?

> В 2007 появилась нашумевшая статья* о том, что RAID5 через два года
> придёт конец из-за URE=10^-14. Остальные риски для автора не имели значения.

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

> Получилось интересное помешательство.

В вопросах storage вообще нездоровое количество маркетингового булшита и предрассудковю Поэтому я прежде всего верю своим глазам. Отсюда же и довольно бескомпромиссная реакция на "csum failed без IO Error". Видел такое -> бывает -> маркетинг и теории идут в пень, без компромиссов и дискуссий. И я уже не скажу что не знал что так бывает. Знал и должен учитывать эти данные в принятии решений.

> Часть людей поверила в рассказ про RAID5 и URE,
> не задумываясь о том, что реальный URE гораздо ниже.

Ну это тоже раз на раз не приходится. Воооооон та сыпучка с которой пример - куда злее. Если ее записать, кинуть недельку поваляться и проч - scrub найдет с дюжину рандомных осыпонов. И это факт. Который я могу повертеть в руках. И я не могу сказать что так не бывает, получив столь вопиющий факт в руки. Другое дело что и тут можно проблему классифицировать. Это вероятнее на флешовых устройствах, чем дешевле и low end тем вероятнее такой расклад. Но вообще FEC может быть пробит. Вероятность этого далеко не ноль. На самом деле я просто подружился с FEC до уровня "имлементера" по своим причинам и проинформировал себя о реальных свойствах алго - а не измышлизмах.

> типа Toshiba N300 16TB. Что без избыточности (RAID/DUP) такие диски должны
> быть не бесполезны, а даже опасны. Что их SMART должен плодоносить ошибками.

А таки btrfs по дефолту вернули DUP на SSD. Догадаетесь почему? Повышает выживаемость файлух у юзерей. По крайней мере не дает метаданные урыть - а данные, ну, да, это плохо, но масштаб урона при сносе метаданных куда как.

> теории во время обычной работы должно происходить постоянное исправление бэдов, невозможное
> в RAID0.

Сам стораж вообще не может починить "UNC" - а как? Но если файлуха забьет на эту копию, возьмет из другой, а эту деаллоцирует или перезапишет, проблемный сектор таки более не нужен и получит запись в него - и вот тут уже фирмварь сможет посмтреть читается ли это, и если нет то сделать этому ремап. Без потерь данных.

>> про (не)надежность ФС лечить - это не находит моего понимания.
> Говоришь как тот адепт ZFS. Ветка почти началась с коммента про скорость
> (второй в ветке, не мой). Дальше говорил о цене фич,

Ну как бы адепты ZFS были первыми кто это осознал. Просто их звездолет на паровой тяге и гипердрайв с их стимпанк технологиями очень уж сыкотно выглядит. Но даже так они поняли ряд тех вещей которые понял я.

> о пофайловом сжатии и снапшотах, которые бы добавлялись без
> компромиссов ("Парето-оптимально"), о шифровании, о чексуммах-для-данных-
> на-уровне-ФС как приятном бонусе.

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

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

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

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

У меня есть и просто "особо мерзенькие девайсы" :).

И кстати если мы про это...

* [new tag]                   v6.7-rc1   -> v6.7-rc1

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