>> Опять двадцать пять. Начинай сначала.
> Ну так я не виноват что ты тугой и до тебя медленно
> доходит: вполне возможна ситуация, когда диск был 1, на нем хаотично
> вылезли бэды например. Это типичный десктопно-ноутбучный юзер. Все что сможет ФС
> - констатировать bad checksum. А восстановить это - не сможет.

Наконец-то дошло! Ты делаешь успехи. А теперь прочти, что я написал РАНЕЕ про "zpool scrub poolname", что в результате его работы мы имеем. Не трудись: список повреждённых файлов с полными путями. Для вашего fsck, запускаемого по дефолту как "fsck -y", возможна только файло-помойка в каталоге /lost+found.

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

Дело в том, что scrub обозначает повреждённые файлы и одновременно производит очистку ФС. И ФС после его работы считается де-факто в консистентном состоянии (свойство CoW + очистка scrub). Выколупывать какие-то ошмётки после scrub, конечно можно, они будут либо полностью отсутствовать, либо находиться по тем же путям, что и ранее имевшиеся файлы, даже имена файлов будут те же, но это уже будут не "те данные" — доставай из бэкапов, чуда не будет.
---
Для сведения к минимуму риска повреждения данных в ZFS применяется расчет контрольной суммы, обеспечение избыточности данных и их самовосстановление. Тем не менее, повреждение данных может происходить в том случае, если пул не является избыточным, при повреждении во время нахождения пула в состоянии DEGRADED или в результате ряда маловероятных событий, приводящих к повреждению нескольких копий фрагмента данных. Вне зависимости от причины, результат одинаков: данные повреждены и, следовательно, недоступны. Предпринимаемое действие зависит от типа поврежденных данных и их относительной значимости. Возможно повреждение двух основных типов данных:

* Метаданные пула – ZFS требует некоторых данных для открытия пула и обращения к наборам данных. При повреждении этих данных весь пул или целые ветви иерархии набора данных становятся недоступными.

* Данные объектов – в этом случае повреждение происходит в рамках определенного файла или каталога. Эта проблема может привести к тому, что часть файла или каталога становится недоступной, или объект может оказаться полностью неработоспособным.

Данные проверяются в нормальном режиме работы, а также в процессе очистки.
---

Всё равно: в случае с ZFS у нас на руках список повреждённых/отсутствующих файлов ("zpool status -v"), а вслучае fsck —  сваленные в кучу "какие-то" ошмётки неизвестно чего в /lost+found. Вот и догадайся в последнем случае, что это было и что именно нужно восстановить.

> Да, некоторые файлы могут быть испорчены. Хорошо если ФС или fsck
> их как-то пометит как таковые. Но выцепить то что осталось с
> тома проще всего когда он примонтирован, копированием. Для этого том должен
> быть доведен до моунтабельного состояния. Утилитой-чекером.

Ещё раз: "zpool import -F poolname" — импортирует полностью убитый (FAULTED) пул, если есть хоть малейшая надежда хоть что-то с него выцепить. fsck традиционных ФС в таких же случаях ничего не может предпринять кроме разрушения пользовательских данных ради приведения в порядок структуры ФС.

> Кстати, а расскажи, как мне RAID в ноуте забабахать, если там чисто физически место для 1 HDD и более нишиша?

В некоторых ноутбуках от SONY есть место для двух 2,5" HDD. Сам подумай, как можно сделать из них mirror.
В обычных ноутбуках, как правило, место только для одного HDD/SSD. Тут уж не до избыточности, а вот верифицируемость данных важна, особенно на ненадёжных MLC SSD.

>>> А почему RAID должен помогать в починке метаданных ФС?
>> А почему нет, если он интегрирован с ФС?
> Да хотя-бы потому что RAIDить может быть и некуда. Ну понятное дело
> что ZFS не ориентирован на мелкие инсталляции "перец с ноутом", все
> что они смогут сказать - "сам дурак".

В настоящий момент я бы не отказался от ZFS на ноутбуке, у которого минимум 4 ГБ ОЗУ и процессор уровня двухъядерного AMD Athlon II 2 ГГц. Всё, что не слабее этой аппартаной конфигурации, должно довольствоваться UFS2 с Soft Updates или NTFS, но никак не динуксовыми ФС, теряющими данные на ровном месте.

> А вот btrfs очень
> даже ориентирован на такое применение. Поэтому там не катит говорить "сам
> дурак". Там чинить придется, а потребовать пять дисков для рэйда -
> не катит.

Btrfs для высоких уровней RAID использует средства mdadm. До сих пор нет поддержки нативной реализации RAID-5. Только недавно в GRUB2 обеспечили возможность загрузки с Btrfs. Что ещё можно обсуждать?

>> Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :))
> Просто btrfs рассчитан на немного более широкие сценарии, в частности и на
> ноуты там всякие, где разместить многодисковый рэйд попросту негде. Так что
> неизбежно придется отколупывать юзверям их диски из весьма неприглядного состояния и
> скорее всего не имея зеркальной копии всех метаданных.
>> Почему свою? Это ваша тупость, данная вам в ощущениях.
> Мои ощущения говорят мне что мой ноут с 1 диском как-то сложно сделать осмысленным RAIDом.

Вперёд, читать про восстановление ZFS после сбоев: http://download.oracle.com/docs/cd/E19253-01/820-0836/gavwg/...