>[оверквотинг удален]
>> добил уже ранее деградировавший пул. Ну не повезло человеку, вернее ССЗБу,
> Не вижу, что помешает тому чтобы такое же "везение" посетило и остальных.
> Как бы fsck и нужен в случае когда не повезло. RAIDы
> вообще очень надежны в теории, а при реальных непредсказуемых глюках оборудования
> и отказах - больше похоже на лотерею. Оборудование имеет свойство подыхать
> совсем не так как было задумано в RAID-ах, поэтому надеяться на
> то что слой RAID-а однозначно спасет - лично я бы не
> стал. Потому что прецеденты странной смерти оборудования - бывают. При этом
> бывает все что угодно и совсем не в том виде в
> каком было задумано :D.Да. Бывает на традиционных ФС, где ФС и менеджеры томов не знают о сквозной целостности данных, которые они обрабатывают и хранят. Типичный случай: рассинхронизация классического RAID-1. Кто знает, почему такое происходит довольно часто, что приходится периодически запускать специальную утилиту верификации от производителя RAID? Нет ответа.
>[оверквотинг удален]
>> И то, структуры он особо не переколупывал. Пытался просто откатить
>> последние транзакции. Нынче для этого уже ключик -F к zpool import придумали для автоматизации процедуры.
> Да-да, один конкретный сценарий - заткнули. Проблема только в том что таких
> сценариев - over 9000, и поэтому нормальный подход это утиль который
> сделает проход по метаданным, проверит их на вменяемость и исправит заведомо
> попорченные данные, перестроив их (if possible) или хотя-бы нейтрализует их до
> логически непротиворечивого состояния (почистит). Ну, чтобы можно было все это смонтировать
> по человечески и вынуть то что уцелело. На случай если нет
> актуального бэкапа или там что еще - must have.
Это вы сейчас zpool scrub описали?
> Тем более что ресторить 100500дисковый пул с бэкапа занимает туеву хучу времени.
Опять же, для ZFS быстрее ресторить отдельную ФС из бэкапа, так как повреждения файлов локализуются в отдельных ФС. Восстановление отдельных ФС делается очень быстро — быстрее, чем поблочное копирование RAW-устройств, так как в бэкапных снимках сохраняются данные только файлов, а не тома.
> Идеальное
> решение - убрать с сбоящего диска данные (btrfs сие умеет, например),
> прогнать проверку, посмотреть чего побилось, воткнуть новый диск, отребалансить на него
> данные, восстановить из бэкапов то что пострадало.
Что, Btrfs уже научилась самостоятельно RAID-5 без всяких посторонних менеджеров томов?
> А то если из-за
> бэдов реально убилось только пару файлов - тупо раскатывать весь массив
> на 100500 дисков из бэкапа. Это ж долго и геморно что
> пипец.
zpool scrub в статусе проверенного пула как раз-таки сохраняет информацию о повреждённых файлах с полными путями к ним — легко восстановить из бэкапа.
fsck обычных ФС (молитесь, чтобы в Btrfs было хоть какое-то подобие scrub) обычно складывает неидентифицированные файлы кучей в /lost+found.
> Проблема в том что fsck умеет (должен уметь) это намного лучше и продвинутее.
Так умеет или должен уметь? Назовите прецедент, где fsck восстановил из повреждённых файлов хотя бы один. Да ему наплевать на пользовательские данные — он ремотирует ФС, а найденные обломки сложит кучкой и всё.
> Опять же, глюки бывают разные. А как насчет того что в каком-то локальном месте грохнется обе копии метаданных?
А избыточность на что? В Mirror этих копий метаданных достаточно, чтобы определить, какие метаданные уцелели, а какие нет, заменить сбойные. То же самое с повреждёниями файлов на одном из резервируемых носителей — ZFS просто не отдаст неверные данные операционной системе, а восстановит их из уцелевших с одного из носителей (сделает резервную копию), на что традиционные ФС просто неспособны. Традиционные дешёвый аппаратный или программный RAID-1 со сбойным носителем будет отдавать мусор, пока не запустят утилиту верификации блоков данных RAID.
> Глюки как-то не очень выбирают где им вылезти, поэтому они могут и
> метаданные накрыть. Знаете какие чудеса например на диски пишутся если контроллер
> на котором пачка дисков висит немного подглючил раз в сто лет
> и половина пачки дисков ушло оффлайн а потом вернулось онлайн и
> так несколько раз, да еще с записью порции вермишели мимо цели?
Во-первых, давайте не разводить дискуссий, в которых прослеживается явное незнание матчасти по работе (испорченного, в том числе) пула.
Во-вторых, сначала подтвердите свои измышления практикой: создайте собственные ZFS-пулы и поэкспериментируйте с ними. А то от вас очень много болтовни феерической глупости.
