Ли Linux гарантирует, что содержимое файла будет сброшено на диск после закрытия()?

Ответ 1

От "man 2 close":

Успешное закрытие не гарантирует, что данные были успешно сохранена на диске, так как Ядро исправляет записи.

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

Ответ 2

Нет, закроет not выполнить fsync (2) и будет убивать многие машины до смерти, если это произойдет. Многие промежуточные файлы открываются и закрываются их создателем, затем открываются и закрываются их потребителем, а затем удаляются, и эта очень общая последовательность требует касания диска, если close (2) выполнил автоматический FSYNC (2). Вместо этого диск обычно не тронут, и диск никогда не знает, что файл был там.

Ответ 3

Также важно отметить, что fsync не гарантирует, что файл находится на диске; это просто гарантирует, что ОС попросит файловую систему сбросить изменения на диск. Файловой системе не нужно ничего записывать на диск

из man 3 fsync

Если _POSIX_SYNCHRONIZED_IO не определено, формулировка сильно зависит в документе соответствия, чтобы сообщить пользователю, что можно ожидать из системы. В явном виде предполагается, что нулевая реализация разрешено.

К счастью, все обычные файловые системы для Linux фактически записывают изменения на диск; несчастливо, что все еще не гарантирует, что файл находится на диске. Многие жесткие диски поставляются с включенной буферизацией записи (и, следовательно, имеют свои собственные буферы, которые fsync не скрывает). И некоторые диски/RAID-контроллеры даже лгут вам о том, что они сбросили свои буферы.

Ответ 4

Нет. fclose() не означает fsync(). Многие файловые системы Linux задерживают запись и выгружают их, что повышает общую производительность, по-видимому, уменьшает износ диска и улучшает время автономной работы ноутбуков. Если ОС пришлось записывать на диск всякий раз, когда файл закрыт, многие из этих преимуществ будут потеряны.

Пол Томблин упомянул спор в своем ответе, и объяснение того, что я видел, не будет вписываться в комментарий. Вот что я слышал:

Недавняя разногласия связана с порядком ext4 (ext4 является предлагаемым преемником популярной файловой системы ext3 Linux). В Linux и Unix-системах принято менять важные файлы, читая старый, выписывая новый с другим именем и переименовывая новый в старый. Идея состоит в том, чтобы гарантировать, что либо новая, либо старая будет там, даже если система в какой-то момент сработает. К сожалению, ext4, похоже, рад прочитать старый, переименовать новый в старый и записать новый, что может быть реальной проблемой, если система переходит из этапов 2 и 3.

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

Ответ 5

Нет, это не гарантировано. ОС имеет собственное кэширование. Все близкие по сути гарантии - это то, что буферы программ покраснели в ОС, но ОС все еще может держать на себе неписаную информацию. Я считаю, что в мире ядра Linux есть некоторые разногласия, потому что даже fsync не гарантирует, что он покраснел на диск, по крайней мере, в ext3.

Ответ 6

В manpage для open указано:

Чтобы гарантировать синхронный ввод-вывод, в дополнение к O_DIRECT следует использовать O_SYNC.

и что

В общем случае это (O_DIRECT) ухудшит производительность.

С помощью fcntl можно было бы с помощью fcntl установить F_SETFL, чтобы минимизировать эффекты кэша ввода/вывода для каждого чтения и записи там после.

Ответ 7

Вас также может заинтересовать этот отчет отчет об ошибке из базы данных firebird sql относительно fcntl (O_SYNC), который не работает на Linux.

Кроме того, вопрос, который вы задаете, подразумевает потенциальную проблему. Что вы понимаете, записывая на диск? Почему это имеет значение? Вас беспокоит, что питание отключается, а файл отсутствует на диске? Почему бы не использовать ИБП в системе или SAN?

В этом случае вам нужна файловая система журналов, а не только файловая система журналирования метаданных, но полный журнал даже для всех данных.

Даже в этом случае вы должны понимать, что помимо O/S-приложения, большинство жестких дисков лежит на вас о выполнении fsync. - fsync просто отправляет данные на диск, и зависит от конкретной операционной системы, чтобы узнать, как ждать, пока накопитель сбросит свои собственные кеши.

- jeffk ++

Ответ 8

Я не думаю, что Linux может гарантировать это, поскольку сам диск также может кэшировать данные.

Ответ 9

Нам не пришлось бы заботиться об этом, если бы компьютер/ОС имел отказоустойчивую файловую систему, которая гарантировала бы запись на то, что пережило силовой цикл, по крайней мере для файлов, на которые мы положили это ограничение. Он не должен быть диском, если есть некоторая энергонезависимая оперативная память или эквивалент. Некоторые мейнфреймы временного возраста, которые я смутно помню, имели такие механизмы и якобы делали такие гарантии.