>[оверквотинг удален]
>>>delayed allocation для конкретного файла) приложений можно встроить в существующий интерфейс.
>>>По дефолту всё должно быть надежно.
>>
>>Да вы долбанулись - вы сами приказали ФС открыть файл СО СТИРАНИЕМ
>>ДАННЫХ. open(name, O_CREAT | O_TRUNC, 0666)
>
>Ой, какой феерический бред. Приведенные флаги - означают, что создается новый файл,
>и если на его месте что-то уже было, стереть его. Но
>и только. Это вовсе не означает, что вновь создаваемый файл после
>этой точки - будет стёрт.

Так бага то в том, что новые данные в новый файл ЕЩЕ НЕ ПОПАЛИ из-за краха системы.

Хотя подумал над:
>В том же open(2) есть флаг открытия файла в синхронном режиме, когда write() не будет возвращаться без реальной записи.

наверное в этом случае ext4 даже примонтированная с -o delayed-allocation (или как оно там) ОБЯЗАНА сбросить данные до возврата из write().

типа переписывание кривых приложений на:
open(name, O_CREAT | O_TRUNC | O_SYNC, 0666) - спасет, но только тех, кто успевает сделать:
write().

Т.е.
open(name, O_CREAT | O_TRUNC | O_SYNC, 0666)
write()
=> тут сбой - но все уже хорошо.

open(name, O_CREAT | O_TRUNC | O_SYNC, 0666)
=> тут сбой.
write()

В этом случае опять получаем обнуление.

Решение проблемы:
fs.begin()
open(name, O_CREAT | O_TRUNC | O_SYNC, 0666)
write()
fs.commit()

В какой бы точке не был сбой - либо файл еще truncated и потому старая конфигурация ЛИБО уже записаны все новые данные. Но это уже транзакционный API