В некоторых файловых системах при создании файла необходимо вызывать fsync() не только для самого файла, но и для родительского каталога, чтобы сделать создание файла долговечным. В противном случае запись каталога может потеряться при некорректном размонтировании; файл inode будет осиротевшим.
Это все еще актуально для ext4, или об этом позаботится журнал?
Многие приложения (например, vim, как проверено strace) вызывают fsync только для файла. Это безопасно?
Обновление: Вкоммит 14ece1028b3ed53ffec1b1213ffc6acaf79ad77cв ядре ext4 специально изменена таким образом, чтобы,с отключенным журналированием, запись родительского каталога автоматически fsync()ed при fsync()ing самого файла. Но что насчет включенного журналирования? Является ли каталог fsync() неявным, поскольку он является частью той же транзакции, что и создание нового inode?
решение1
Я бы сказал, что «это зависит» отчасти, поскольку в ext4 можно изменить параметры журнала таким образом, чтобы регистрировались целые файлы или только метаданные, а то, будут ли они немедленно зафиксированы, отчасти зависит от конфигурации оборудования.
В случае, если ext4 смонтирована как минимум с журналированием метаданных и подсистема не кэширует записи, я бы рекомендовал вам не выполнять fsync для каталога.
Однако, изЛарссон «ext4 против fsync»:
Следует отметить, что POSIX и даже ext4 не дают никаких гарантий, что файл сохранится после сбоя системы, даже при использовании fsync.
Неполный ответ, но обсуждаемый пост в блоге подробно описывает проблемы журналирования и потери данных. Хотя он и не новый, я считаю, что он по-прежнему отражает статус ext4 сегодня, и его комментарии о том, когда использовать fsync, а когда нет, заслуживают внимания.