> все же щупал однокурсницу :-(

Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования лекций CS западных вузов, по частной инициативе, с уклоном в современный state of art и практические применения. Поэтому мои знания имеют уклон в практические кейсы. Я понимаю основы и меня нельзя напугать какой-нибудь "дистанцией хэмминга" или полиномиальной математикой, да даже то что ридасоломон на полях галуа делает.

Тем не менее, я пожалуй признаю что погорячился насчет заяв что CRC совсем не алгоритм коррекции. Некое его применение в этом качестве и правда возможно, так что в этом смысле я пожалуй погорячился.

> практическое - kernel panic при попытке прочитать.

Я что-то сравнимое видел 1 раз. В тестах, с -rc ядрами. На специфичной конфиге. Кредитсы по итогам разбора полетов (да, я впрягся и этого бага с нами уже нет) - ушли господам из mm/ с их рефакторами - реФАКтор вышел. Btrfs-ники виноваты тем что у них вылезло. Наверное и где-то еще, просто "где баг нашелся - там и гасится". Btrfs-ники компетентно и быстро вывели на чистую воду, пнули господ mm/, те резко зафиксили, я через полдня уже вертел патч фиксящий все это великолепие. Подтвердил что трабл починен, комитнули в майнлайн, вот, отлично, релиз не профакапили. Люблю хэппи энд :P.

> потому что опыт ограничен одной сыпучей флехой.

Неа. Еще оно несколько раз вполне успешно парировало редкие рандомные бэды, а еще у меня появилась коллекция глюкастиков - от шнурка до проца. И даже, вот - я ж писал что чуваку с энтерпрайзным ssd пул от разлета спас. А фигли, гад делал примерно то же что и флеха, только активнее. Чувак думал что это баг btrfs. Оказалось - сыпящийся SSDшник. Я понаблюдал, он такой дажеко не 1, лучше всего на это любители bcache (не того который fs) нарываются.

> А на деле оно портится в памяти.
> (поэтому от корректирующего кода действительно ноль пользы)

Прикинь, в моей коллекции есть и несколько битых модулей памяти. И кроме всего прочего - я пользуясь случаем и немного поизучал как именно failure mode выглядит.

Это как-то так: оно обычно видит CSUM error, вопит в лог, читает 2 копию, фиксит. На самом деле это не очень надо было (на стораже данные норм чаще всего), но кроме всего прочего это чинит буфер в RAM и проч, апликухам левак не уходит. Но самое главное - кривой хардвар хайлайтится. Да, вот тут с теорвером уже не стоит в кошки-мышки играть, проиграть однажды уже вполне реально.

Я даже видел пару типов которые такой джекпот выиграли. На самом деле - в "зале" есть пара граждан которые изумительно просекают это, и ор на флипнутый бит в деревьях детектят влет (там есть некий sanity check). И вот тут - если "everything failed" можно гада реально флипнуть хексэдитором, но это для тех кто понимает дизайн и может такие вещи. Актуально только если избыточности ну вот не было, иначе оно само починит метаданные из другой копии, проблема прозрачно аннулируется и никакого хардкора. При том даже на 1-дисковой конфиге оно с неких пор DUP для метаданных делает, послав всех экспертов с "SSD дедублицирует, блаблабла" в пень - real world эксперименты показали что выживаемость ФС с DUP как метаданные - улучшается.

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

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

На практике - таки обычно недурно парирует. Даже, вот, отгрузку трухи протертым энтерпрайзным SSD выживало, чувак думал что это баг btrfs. Пришлось объяснить что это "хана его энтерпрайз SSDшнику", а вовсе не.

> смотря что за метаданные и что за бэд

Ну и с btrfs'ом все примерно так же. Тем более что метаданные почти всегда дублированы. EXT4 так не умеет, однако.

> (не бывает у меня "бэдов",

Угумс. И труху накопители не возвращают. А как ты с нтфс и EXT4 это проверял то?

> выкинь уже свою флэшку)

Зачем? Кому баг, кому фича - теперь это реалистичный стресстест косплеящий вон то, возврат гамна без IO error наверх. Я и кентовскую штуку погоняю так - когда он привинтит некоторые запчасти на место, сейчас это еще малость негуманно.

> смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное
> место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное
> состояние, потеряешь только то что уже необратимо повреждено.

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

> За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью -

EXT4 явно менее 30 лет...

> ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без
> журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще
> выкинуть чем разбираться.

Вот после каких-то таких прецедентов они кроме всего прочего приделали к журналу чексумы. Но между нами - это сейчас как обсуждение проблем джижка ржавых жигулей.

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

Ну так я о чем. Когда btrfs консистентный, то и данные обычно все же - в юзабельном формате. А базы таки - кастомные зверушки. Ими вообще лучше не заниматься если не понимать основы их механики, журнала, commit/rollback и прочего, иначе горя хлебнуть можно. А если это понимать - окей, можно осмысленно стыковать фичи движка и ФС, не вижу особых проблем. И если кому надо NOCOW - пусть сам и косплеит ФС, от вон того останется только управление местом/аллокацией по сути. Но БД чаще всего именно этого на самом деле и хотели. Они б и на RAW раздел бы, если б не было столько гимора с его администрированием.

А в случае сабжа - баг таки весьма нишевой вышел, бэкпортеры бэк-испортили, и весьма резво заметили :). Это даже не к EXT4 претензия как таковая.