Гарантирует ли Linux, что содержимое файла записывается на диск после close ()?

Question

Когда файл закрывается с использованием close() или fclose() (например), гарантирует ли Linux, что файл записан обратно на (постоянный) диск?

Что я имею в виду, если close() возвращает 0, а затем сразу же после сбоя питания, ранее записанные данные гарантированно сохраняются, т.е.

Системный вызов fsync() предоставляет эту гарантию. Достаточно ли закрыть файл?

Я не могу найти ничего, что может так или иначе претендовать на данный момент.

---

Вопрос 2:

Если close() неявно выполняет fsync(), есть ли способ сказать, что нет?

Answer 1

Из "man 2 close":

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

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

Answer 2

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

Answer 3

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

из man 3 fsync

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

Справочная страница для open говорит:

Для обеспечения синхронного ввода-вывода необходимо использовать O_SYNC в дополнение к O_DIRECT .

и тот

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

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

Answer 7

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

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

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

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

- jeffk ++

Answer 8

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

Answer 9

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