> Все постоянно ссылаются на один и тот-же пример с лисяры, где товарищ
> добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу,Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных. Как бы fsck и нужен в случае когда не повезло. RAIDы вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать совсем не так как было задумано в RAID-ах, поэтому надеяться на то что слой RAID-а однозначно спасет - лично я бы не стал. Потому что прецеденты странной смерти оборудования - бывают. При этом бывает все что угодно и совсем не в том виде в каком было задумано :D.
> угробил из 3-х дисков в raid-е 2.
Я и более прикольные рассыпоны многодисковых рэйдов видал. Это у него еще так, ерунда. Обычный бэд, относительно безобидный сценарий. Бывает намного хуже.
> И то, структуры он особо не переколупывал. Пытался просто откатить
> последние транзакции. Нынче для этого уже ключик -F к zpool import придумали для автоматизации процедуры.
Да-да, один конкретный сценарий - заткнули. Проблема только в том что таких сценариев - over 9000, и поэтому нормальный подход это утиль который сделает проход по метаданным, проверит их на вменяемость и исправит заведомо попорченные данные, перестроив их (if possible) или хотя-бы нейтрализует их до логически непротиворечивого состояния (почистит). Ну, чтобы можно было все это смонтировать по человечески и вынуть то что уцелело. На случай если нет актуального бэкапа или там что еще - must have. Тем более что ресторить 100500дисковый пул с бэкапа занимает туеву хучу времени. Идеальное решение - убрать с сбоящего диска данные (btrfs сие умеет, например), прогнать проверку, посмотреть чего побилось, воткнуть новый диск, отребалансить на него данные, восстановить из бэкапов то что пострадало. А то если из-за бэдов реально убилось только пару файлов - тупо раскатывать весь массив на 100500 дисков из бэкапа. Это ж долго и геморно что пипец.
>> если невозможно то хотя-бы нейтрализует его до состояния в котором том
>> (и вообще пул) можно смонтировать без приключений.
> Да умеет ZFS это само, причем на лету.
Проблема в том что fsck умеет (должен уметь) это намного лучше и продвинутее. Он может позволить себе именно техники анализа и перестройки/нейтрализации метаданных, которые геморно впихивать в драйвер ФС. А что там ZFS умеет - видно на примере пресловутого лисяры. Вот в таких случаях это должен быть универсальный пинок fsck который отколупает то что отколупывалось и сделает ФС монтируемой.
> В zfs метаданные хранятся в 2-х экземплярах, а глобальные, вообще в 3-х. да еще и
> с контрольными суммами, причем сквозными для всей транзакции, т.е. ФС может
> в любой момент понять какая копия правильная. И инициировать принудительную
> проверку так-же легко одной командой.
Опять же, глюки бывают разные. А как насчет того что в каком-то локальном месте грохнется обе копии метаданных? Потому что гладиолус^W глюк случился именно вот так, а не как-то иначе? Ну допустим проверка даже обнаружит что там - опа. А дальше что? Хексэдитором в ФС, как парень с лисяры? Вот админам больше делать нефиг.
> Если просто пострадали файлы, ZFS без проблем монтируется и работает в rw
> режиме без всяких ограничений.
Глюки как-то не очень выбирают где им вылезти, поэтому они могут и метаданные накрыть. Знаете какие чудеса например на диски пишутся если контроллер на котором пачка дисков висит немного подглючил раз в сто лет и половина пачки дисков ушло оффлайн а потом вернулось онлайн и так несколько раз, да еще с записью порции вермишели мимо цели? При таком для некоего файла могут оказаться испорчены вообще все копии метаданных. И чего? За хексэдитор? Или из-за 1-2 засранных файлов весь немеряный массив перераскатывать из бэкапа?
> При этом еще и пишет в zpool status, какие конкретно файлы пострадали.
> Проверенно эксплуатацией машин с глючными sata-контроллерами.
> А убить несколько копий метаданных еще постараться надо. Хотя, согласен, у
> некоторых получалось.
При развале многодисковых конфигураций факап сразу по нескольким дискам - довольно частое явление природы. Особенно если взглюканул чипсет контроллера на котором висела куча дисков. RAID-ы при таких глюках имееют свойство эпично лажаться, т.к. на произвольный отвал группы дисков или запись порции левых данных на сразу несколько дисков они разумеется не рассчитаны.
[...]
>> технические упущения красивым маркетингом.
> Ну, ZFS это определенно не техническое упущение. Это флагман в своем классе.
> btrfs и hammer явно еще не успели стать взрослыми.
Они были первыми, и этого не отнять. Но новые дизайны будут лучше. Потому что учтут старые упущения + им не надо держать совместимость с старым форматом или делать утили конверсии форматов. Это нормально, это жизнь.
