> Так запишется или нет?Может быть запишется, а может быть нет. А может быть и не всё.
> Если запишется, то, очевидно, вся транзакционная группа DMU.
Не факт. Реордеринг записи имеет место быть - поэтому и не выживают СУБД без BBU.
> Если не запишется (питание вырубилось, батарейки нет), то ZFS останется в том состоянии, в котором была до записи транзакционной группы DMU
Транзакционность обеспечивается write barrier'ом. Когда оно не работает, а данные записываются в порядке 100500 - 999 - 1 - 768 - 993 - 998 - ... - ни о какой непротиворечивости и речи быть не может. Поэтому батарейка для кеша обязательна.
> Если носитель "протёртый до дыр", то с ним никакая ФС не будет
> нормально работать.
А при чём тут протёртый до дыр носитель?
> Не бывает такого, чтобы на ZFS файл не до конца модифицировался и
Это в штатных условиях. А в нештатных - см. выше.
> к такому ПО, и у них (у нормальных СУБД) есть собственная
> подсистема журналирования транзакций с возможностью отмены незавершённых транзакций
Которая также расчитана на транзакционность железа. Совершенно нештатный режим (контроллер с активным writeback кешем, но без BBU) - убивает эту логику полностью.
> Ты описал типичную ситуацию проблемы "Write hole" для аппаратного RAID-5.
> Вкратце: http://phpsuxx.blogspot.com/2010/08/raid-z.html
Это не write hole, это ХУЖЕ. Тут объем - не страница R5, а совершенно произвольный. Может даже так случиться, что последние поступившие 400-500 Мб запишутся, а первые 2-3 - нет.
> А чего ж не ядерный модуль ZFSonLinux? С FUSE намучаешься.
Лениво мучать ядрышко. С FUSE проще.
