POSIX doesn’t make guarantees on a lot of things. Neither does ISO or ANSI. But all trust implementations “to do the right thing” given the environments of use. For instance, in C, when you call malloc() it’s undefined where the memory comes from or even if all requested memory is available right now. But that doesn’t mean that you can do a malloc() can allocate memory in video memory (messing up the screen) or read-only memory. While such behaviour is technically legal according to ISO/ANSI, it’s not reasonable behaviour.

If ext4 wants to be taken seriously as a desktop file system, it must have reasonable behaviour in cases common to desktops, and that includes gracefully surviving failures such as crashes or someone tripping over the power plug.

Thankfully, ext4 seems to be fixed.

I mean rename(2) here, of course.

1. The rename(2) call operates on directory pathnames only. This is explained by Ted nicely here: http://lwn.net/Articles/323745/. The fact that kernel can present a consistent picture to processes (in terms of both the directories and files) is related to the fact that, of course, kernel keeps track (internally) of where directory entries point to, which has nothing whatsoever to do with persisting directories or files to disk.

2. It is clear from the documentation of fsync() that separate calls to commit directories and files _can_ (and should) be made. This clearly spells out that these are two different entities, which users can commit to disk at will.

3. In the absence of fsync(), the order of commits of both files and directories is generally not specified, which means that kernel is free to do as it pleases.

Now, any talk of barriers, transactions and what not is just wishful thinking in the current API. There is simply no guarantees to it and programming to such guarantees is completely non portable.

Claiming that a particular file system not implementing such guarantees is broken is false. We all got bitten by this, unfortunately, and the problem is in the application code.

The problem of configuration files being zeroed on a crash (which should be a rare event) can be solved by using backup files, even in the absence of constant fsync(). An example (probably not a very good one) is here: http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/#comment-2239.

If anyone like to run ext4 on opensuse – http://linuxpoison.blogspot.com/2009/01/ext4-support-on-opensuse-111.html

Such O_TRUNC_ATOMIC behaviour is very unlike normal posix/unix behaviour. So its probably both hard and not a good idea.

About ext4 dependency tracking, thats exactly what the patches in 2.6.30 does.