Почему закрытие файла ожидает синхронизации при перезаписи файла, а не при создании?

Это звучит как напоминание о O_PONIESфиаско, которому совсем недавно исполнилось 11 лет.

До того, как появилась ext4, ext3 приобрела своего рода репутацию стабильной системы при перепадах мощности. Он редко ломался, редко терял данные из файлов. Затем ext4 добавила отложенное выделение блоков данных, то есть даже не пыталась немедленно записать данные файла на диск. Обычно это не проблема, если данные в какой-то момент туда попадают, а для временных файлов может оказаться, что вообще не нужно записывать данные на диск.

Но ext4 записала изменения метаданных и зафиксировала, что что-то изменилось в файле. Теперь при сбое системы файл помечался как усеченный, но записи после этого не сохранялись на диске (, так как для них не выделялись блоки ). Таким образом, в ext4 часто можно увидеть недавно -измененные файлы, обрезанные до нулевой длины после сбоя.

Это, конечно, было не совсем то, чего хотели большинство пользователей, но был выдвинут аргумент, что прикладные программы, которые так заботятся о своих данных, должны были вызывать fsync(), и если они действительно заботились о переименованиях , они также должныfsync()(или, по крайней мере,fdatasync())содержать каталог. Однако никто так не делал -, отчасти потому, что на ext3 fsync()синхронизировал весь диск, возможно, включая большие объемы несвязанных данных. (Или настолько близко ко всему диску, что разница в любом случае не имеет значения.)

Теперь, с одной стороны, у вас была ext3, которая плохо работала с fsync(), а с другой — ext4, которая требовала fsync(), чтобы не терять файлы. Нехорошая ситуация, учитывая, что большинство прикладных программ заботятся о реализации специфического поведения файловой системы -даже меньше, чем о жестком танце с вызовом fsync()в нужные моменты. По-видимому, было даже непросто выяснить, смонтирована ли файловая система как ext3 или ext4.

В итоге разработчики ext4 внесли некоторые изменения в наиболее распространенные критические -кажущиеся случаи

• Переименование файла поверх другого. В работающей системе это атомарное обновление, которое обычно используется для установки новой версии файла.
• Перезапись существующего файла (вашего дела ). Это не атомарно в работающей системе, но обычно означает, что приложение хочет, чтобы файл был заменен, а не усечен. Если перезапись выполнена неудачно, вы также потеряете старую версию файла, так что это немного отличается от создания совершенно нового файла, где при отключении питания -будут потеряны только самые последние данные..

Насколько я помню, XFS также демонстрировала аналогичные файлы нулевой -длины после сбоя еще до ext4. Однако я никогда не следил за этим, поэтому я не знаю, какие исправления они бы сделали.

См., например,. эта статья о LWN, в которой упоминаются исправления:ext4 и потеря данных(март 2009 г.)

_{В то время, конечно, были и другие работы об этом, но я не уверен, что полезно ссылаться на них, так как это в основном вопрос указывания пальцами.}