>> Ну есть zdb если на то уж пошло.
> Он может проверить все структуры на валидность и починить все что невалидно
> или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то
> что уцелело?

http://www.freebsd.org/cgi/man.cgi?query=zdb

>> блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога.
> А теперь представьте себе что цепочка логов порушилась где-то в середине. Или
> метаданные описываюшие оную.

То только эта цепочка и будет недоступна.

>> Во время же выделения мы проигрываем лог.
> Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования.
> Тогда как fsck обычно пользуются лишь тогда, когда эта логика не
> смогла отработать как надо.

В самом деле?
https://osu.redhat.com/content/courses-ru/rha130-50-2-ru/tag...
---
Использование команды fsck
Команда fsck обычно вызывается с именем раздела, который нужно проверить, в качестве единственного параметра. Если команда fsck найдет ошибку, которую она сможет исправить без риска потери данных, она исправит ее. Если есть риск потери данных, команда fsck приостановится и выдаст сообщение с вопросом, должна ли она исправлять ошибку. Для администраторов, которые не обладают подробными знаниями в области внутренней структуры файловой системы ext2, выбор невелик. По правде говоря, команда fsck часто запускается с ключом -y, который так и говорит: "Не спрашивать, просто делать".
---

> Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной.

А он у вас есть? Бэкапы хотя бы сделали? :))

> А вы в вашем праве превращаться в лепешку, если вам так удобнее.

У нас хотя бы мусор из-за бэд-блока на одном носителе можно достоверно обнаружить, а на группе носителей в RAID невозможен в принципе.