> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять.Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. Но по мере роста числа битов на брутфорс, наивное "декодирование" станет крайне ресурсоемким.
> Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал,
> какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть.
В контексте btrfs-а меня интересует фактическое поведение self heal как ты понимаешь, а не абстрактные возможности сбития автомобилями вертолетов.
> И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных
> по подписке за пару миллионов швейцарских франков, но это неточно.)
Да ну и болт с ним, а? У меня вон там шикарный ридсоломон есть, а вон там "очень странный формат сигнала". Но это к делу не относится. В вон том применении оно сугубо для детектирования ошибок. И есть на выбор несколько других алго для этого.
> и если нам не повезло - нет второй или обе битые -
Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или даже одном но исправном) сектора не прочтутся? А, это произведение вероятностей? А знаешь, вот так мне теорвер намного больше нравится. Если я вдруг смогу такой джекпот на реалистичных read error rate, числе секторов и проч - я тогда в ЛасВегас заеду, посмотреть что еще я могу.
> "всеми щупальцами облизался и спрашивает - и что делать будиииим?!"
Там для совсем параноиков есть RAID1C3 и даже C4. Если у тебя сразу столько сыпется - это чего? :)
> Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?!
В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он смогет? Констатировать что джеппа? Это очень ценно и полезно. И это если еще накопитель вернул io error а не выдал труху, иначе оно могло резко и внезапно скопытиться. Думаешь, CRC на журнал эти кадры от хорошей жизни налепили? Просто реплей кривого журнала - тома замешивает при случае совсем уж в спагетти имени рейзера, прищлось, вот, придумать хоть что-то.
А btrfs даже на 1-девайсовой ФС хранит метаданные как DUP, что очень способствует тому чтобы не узнавать вон то "а что если".
>> Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется
> надо же - в ext2 нет никакой второй копии - а починить ее обычно удается.
Агаблин, теорвер решил постебаться - на глаза попался EXT4 с бэдом под метаданными. Не то чтобы он вообще совсем помер - но это out of service и мануальные фиксы и потеря данных.
Прости но мало кто хочет танцевать окучивая локалхост и откребая какие там еще ошметки, гоняя какие там еще fsck (что на современных объемах занимает немеряно времени). Хотят чтобы просто работало. Btrfs это и делает - пока это возможно. А если мануальное внимание надо - это всяко фейл. Ну и говоря за себя - я данные с такой штуки всяко достану, особенно с помощью вон того зала.
> Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое).
Это как неуловимый Джо. Людям от компьютеров надо чтобы работало. А не чтобы путем заклинаний подымать труп. Если он труп, требующий мануальщины это уже фейл.
Кто мне будет на управляющем одноплатнике жать эникей? И отвечать на вопросы fsck? И на сервере кстати тоже. Да и на десктопе - я проснувшись в каде порисовать собирался, а не с fsck интерфеситься. И вопрос в том какой масштаб задника. Если это 1 бэд в сто лет, DUP его зарулил и на этом все закончилось это одно. Если хардвар осыпается и его надо инить/менять - окей, и чем мне вон то знание древних поможет? Тем что спрячет от меня факап и позволит порушить больше данных?
> если на картинке падают средства проверки - надо найти художника и выколоть
Как там твои средства проверки ZFS'а на тему факапов с копиями копий поживают? Помнится там диагностика проблемы была весьма компромиссным костылем.
> но все реальные случаи - почему-то именно с бырбырфэсе.
Мде? А почему я тогда рекаверил данные с NTFS и EXT4? Если btrfs с умом юзать - он вообще нагибаться ну вот не хочет чего-то. И это... у EXT4 in place запись очень даже деструктивная, в отличие от вон того. Так что если что-то затерлось в EXT4 - это уже совсем навсегда и отменить вообще совсем никак нельзя. Этого физически более нет. А вот в btrfs можно попытаться и выцепить немного более старое состояние если ну вот реально приспичило. Запись же недеструктивана, а GC в общем случае приходит не сразу.
> оно предназначалось для очень странного в те годы варианта быстрый журнал +
> медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже
> когда он появился. И оно предназначено вовсе не для защиты от крэша.
А что мне вообще делать с файлом где новая голова и старый хвост предлагается? Большая часть софта ЭТО жрать не будет. Всякие сжатые форматы словят decode error - и байбай.
> если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало.
У btrfs ответом на него является такая штука как "generation". Оно знает чего хочет (и насколько это актуально) - записи маркированы generation'ом. При серьезных расстыковках не станет маунтиться чтобы не разнести все. Мануально ессно есть ряд опций чтобы все же попытаться заякориться. Но это уже навороты и мануальщина.
> (я, кстати, честно не знаю где у нее и как,
Как минимум generation прописывается довольно много куда. Это нечто типа серийного номера очередного изменения, и по нему видно насколько это то что оно хотело. Если посмотреть логи офлайн вычитывалки и тому подобных продвинутых вещей - там бывает более подробно разрисовано как оно это видит - мол, это блоки такого-то файла, gen такой-то, но мы бы хотели gen такой-то, ищем дальше...
> знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям
> разбирающимся в ней плохо.
У меня btrfs тоже не разваливался. А другим... ну я вот одному гражданину пул спас, сказав что у него ssd осыпается. Он очень радовался что ему вовремя на факап указали. Btrfs это чинил и еще не осыпался, но по логам было понятно что девайс просится в мусорку.
> А теперь представим что это была страничка базы данных и она не
> совпадает с размером или алайментом блока...
Базы по сути сами наполовину файлухи - и используют свою логику журналинга. Это 1 из причин появления NOCOW. Если кто хотел косплеить ФС, с кастомной семантикой - пусть и косплеит, зачем ему вообше мешать? А делать 1 и ту же работу (журналинг, чексуминг, ...) 2 раза - вообще неоптимально. Если кто хотел фичесет EXT4 - btrfs "до кучи" может это ему дать! Но вообще конкретику ессно смотреть надо. Не тот случай когда универсальные ответы вида "а что будет если" есть.
В целом - ФС оказывается в более старом консистентном состоянии. А БД, если ее писал не совсем кретин, своей семантикой должна форсить сброс буферов и фиксацию на диске данных в критичные для нее моменты. Если оно так делало - по идее семантика сохранится, очевидный минус - синк занимает энное время, так что перфоманс БД на CoW с типовыми паттернами - такое себе. Поэтому там и есть фича прикинуться "а я типа тоже EXT4, вот вам inplace патчинг, все как вы любите".
