> Опять же - упрежу тонну треша про "непротиворечивость ZFS":
> "Непротиворечивость" как ZFS, так и BTRFS/ext4 базируется на механизме write barriers.

До сих пор думал, что у ZFS непротиворечивость записи базируется на логике CoW (новые данные не перезаписывают предыдущие), ZIL (динамический журнал намерений системных вызовов дисковых транзакций, пока транзакционная группа DMU не будет сохранена в стабильный пул) и атомарном обновлении uber-блока после записи контрольных сумм.

> В случае активации кеша контроллера WB снимается уже после записи в
> кеш, а на диск данные поступают, как попало - считается, что
> кеш удержится батарейкой, если что. Если батарейки нет - весь этот
> механизм не работает, и данные на диске порой оказываются в странных
> состояниях.

Когда ZFS замечает, что с носителем творится что-то неладное, она перестаёт с ним работать и останавливается, чтобы не угробить записанные данные.

> ext'ам тут несколько проще даже - объем метаданных не так велик, так
> что шанс либо поступить целиком, либо не поступить вообще - более
> высок.

У вас, я смотрю, на уровне вероятности всё работает. :))

> Сразу говорю - не стоит в здравом уме делать то, что сделал
> я - включать кеш контроллера без BBU. Это путь камикадзе -
> и в своем случае я прекрасно понимал, для чего мне это
> надо, и где риски. С планом восстановления на любой случай. А
> в повседневной практике - лучше не повторять. Серьёзно.

Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки в дисковой подсистеме и просто перестанет работать до устранения этих неполадок. Можешь даже задействовать команду "zpool import -F <poolname>" на убитом, как тебе покажется, пуле. ;)