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

Так запишется или нет? Если запишется, то, очевидно, вся транзакционная группа DMU. А уж порядок внутри неё не имеет никакого значения. Если не запишется (питание вырубилось, батарейки нет), то ZFS останется в том состоянии, в котором была до записи транзакционной группы DMU, и ничего восстанавливать не надо — ZFS в непротиворечивом состоянии.  

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

Если носитель "протёртый до дыр", то с ним никакая ФС не будет нормально работать.

>> Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки
>> в дисковой подсистеме и просто перестанет работать до устранения этих неполадок.
> Фокус знаешь в чем? Ровно до момента отключения питания нет никаких неполадок.
> А после отключения InnoDB хоть как будет разрушен - потому что
> часть данных запишется, а часть - нет.

Не бывает такого, чтобы на ZFS файл не до конца модифицировался и остался в "промежуточном" состоянии модификации, если только такой случай прямо не поддерживается в программном обеспечении, которое использует данный файл. СУБД относятся к такому ПО, и у них (у нормальных СУБД) есть собственная подсистема журналирования транзакций с возможностью отмены незавершённых транзакций (rollback). В этом случае ZFS уж точно оставляет файлы в том состоянии, когда они были нормальными, а не забивает их нулями, как некоторые классические ФС при аварийном отказе питания.

> Причем заранее неизвестно, в каких "версиях" будут конкретные блоки - например блоки
> с порядковыми номерами 100498 и 100500 могут оказаться записаны, вместе с
> "правильным" суперблоком и CRC, а блок с номером 100499 - нет,
> не успел.

Ты описал типичную ситуацию проблемы "Write hole" для аппаратного RAID-5.
Вкратце: http://phpsuxx.blogspot.com/2010/08/raid-z.html

> Но если честно - заинтриговал. Наверное, возьму спецом ZFS-FUSE, отдельный диск, и
> попробую воспроизвести - найду еще одну тачку с LSI, сниму BBU,
> выключу кеш на всём, кроме тестового диска, и устрою потерю питания.
> Быстро не обещаю, но протестирую.

А чего ж не ядерный модуль ZFSonLinux? С FUSE намучаешься.