История изменений

Исправление slovazap, 13.10.21 22:13 (текущая версия) :

Как гарантировать, что текстовый файл не побьется при записи, в случае hard reset/poweroff/kernel panic/т.д.?

Никак, потому что, например, железо может накрыться сразу после успешной записи. С точки же зрения кода, который файл записывает, нужно:

флашнуть буфферы, если таковые в коде используются (например, fflush() в случае stdio, std::flush в плюсах, ничего если просто вызывал write())
вызвать fsync() проверив возвращаемое значние
закрыть дескриптор проверив возвращаемое close() значание

После этого ответственность переходит ядру и файловой системе.

В питоне я использую такой паттерн:

with open('foo', 'w') as filedesc:
    # write to filedesc
    filedesc.flush()
    os.fsync(filedesc.fileno())

Какая файловая система устойчива к таким случаям. Встречал, что с ZFS под Linux были проблемы.

Должна быть любая, это её наипервейшая обязанность. Но в Linux большинство ФС кривые, особенно XFS, для которой официально документированное поведение - херить данные. А вот например ZFS на FreeBSD мы stress-тестили на эту тему, проблем не обнаружено. YMMV.

Исходная версия slovazap, 13.10.21 22:11:

Как гарантировать, что текстовый файл не побьется при записи, в случае hard reset/poweroff/kernel panic/т.д.?

флашнуть буфферы, если таковые в коде используются (например, fflush() в случае stdio, std::flush в плюсах, ничего если просто вызывал write())
вызвать fsync()
закрыть дескриптор проверив что close() вернул 0

После этого ответственность переходит ядру и файловой системе.

В питоне я использую такой паттерн:

with open('foo', 'w') as filedesc:
    # write to filedesc
    filedesc.flush()
    os.fsync(filedesc.fileno())

Какая файловая система устойчива к таким случаям. Встречал, что с ZFS под Linux были проблемы.