Default ext3 mode changing in 2.6.30 (updated)

Here’s something for Linux users to be cognisant of – the default mount option for ext3’s journaling is going to changing from “data=ordered” (i.e. data is committed to disk prior to its metadata) to “data=writeback” (i.e. file metadata may be committed to disk before the file data is). This may be down to Ted Ts’o’s fixes for ext3 fsync() latency in that mode which spawned a long thread on the ext4 list.

Update: apparently Ted floated the idea at the 2009 Linux Storage & Filesystems Workshop, in his session “fsync(), rename(), barriers” – the LWN article notes it made people nervous, saying:

This idea was received with a fair amount of discomfort. The data=writeback mode brings back problems that were fixed by data=ordered; after a crash, a file which was being written could turn up with completely unrelated data in it. It could be somebody else’s sensitive data. Even if it’s boring data, the problem looks an awful lot like file corruption to many users. It seems like a step backward and a change which is hard to justify for a filesystem which is headed toward maintenance mode. So it would be surprising to see this change made.

It was later followed by the post script: “[After writing the above, your editor noticed that Linus had just merged a change to make data=writeback the default for ext3 in 2.6.30. Your editor, it seems, is easily surprised.]“.

Given the massive filesystem thread I guess this is going to make for more interesting times on LKML.. ;-/

Update 2: Forgot to mention too that the relatime option will be the default in 2.6.30, so by default the access time of a file will no longer be updated for every read.

6 thoughts on “Default ext3 mode changing in 2.6.30 (updated)

  1. Tim – it’s “relatime” not “noatime” that will be the default, the kernel thread says:

    relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified.

  2. Yep, and that invalidates POSIX and the diagnostic and forensic purposes that atime can serve (at least I seem to use it fairly often – often enough that it only took me a few days of experimenting to determine that relatime was Not For Me).

    There are better ways of designing a filesystem that don’t require you to disable atime for performance.

  3. from a desktop users POV, i think this is great as it will increase performance. And I *really really* hope that this a step that will make desktop responsiveness better in future versions of the kernel.

Comments are closed.