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

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

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

Угу. Это будет также ровно на этапе монтирования.

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

Скорее - на уровне теории, подтверждаемой практикой.

> Попробуй повторить это с ZFS. Уверен, что эта ФС вовремя заметит неполадки
> в дисковой подсистеме и просто перестанет работать до устранения этих неполадок.

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

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

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