Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On some filesystems, when creating a file, it is necessary to call fsync() not only on the file itself, but also on the parent directory, to make the file creation durable. Otherwise, the directory entry could get lost on an unclean unmount; the file inode would be orphaned.

Is that still true for ext4, or does the jornal take care of that?

Many applications (e.g. vim, as verified by strace) seem to call fsync on the file only. Is that safe?

Update: In commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c to the kernel, ext4 is changed specifically so that, with disabled journaling, the parent directory entry is automatically fsync()ed when fsync()ing the file itself. But what about enabled journaling? Is the directory fsync() implicit, since it is part of the same transaction as the creation of the new inode?

share|improve this question

I'd say "it depends" partly, because ext4 can have its journal options changed such that whole files or just meta data is logged, and whether or not these are immediately committed depends partly on hardware configurations.

In the case where ext4 is mounted with at least meta-data journaling and the subsystem is not caching writes, I'd suggest you do not need to fsync the directory.

However, from Larsson's 'ext4 vs fsync':

It should be noted that POSIX, and even ext4 gives no guarantees that the file will survive a system crash even if using fsync.

Not a complete response, but the blog post in question elaborates on journaling and data loss issues. While not recent, I believe it still represents the status of ext4 today and his comments on when to use or not use fsync have merit.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .