>[оверквотинг удален]
>>>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