I think the idea is that power loss is the most likely "crash" type event and battery backup eliminates that. The other ways to crash (eg a hardware lockup) are rare enough that the risk seems worthwhile for the performance gain. Frequently, people brag about the long uptimes they can achieve with Linux so it would seem that having a low crash environment is possible if not likely for some. Certainly backups should be happening with a higher frequency than crashes. I can see the risk/performance trade off working for people once power loss is eliminated.
Originally Posted by movieman
Having said that, there are lots of people (like your typical home user) who care very much about their data, don't have their systems protected by batteries, and don't have elaborate file backup systems in play. These users also find ways of making crashes more likely. For example running out and buying a GPU from either ATI or NVidia and using the speedy binary only drivers (Don't flame, either vendor will significantly increase your likelihood of crashing. Its not like I'm expressing which vendor I believe is better at it ).
So the question becomes: Will ext4 eat my valuable data if I push the crash monsters out of the shadows? Will it eat it better than other file systems? Maybe.
According to the man page, data=ordered is the default:
"This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal."
In ordered mode, only the metadata is protected by journaling meaning that the file system's internal data should always be in good order, but the actual file data could for example be corrupted by an incomplete write.
But then how do we end up with zero length files when we
fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new", "foo")<<<CRASH>>>>
if the file data is written before the meta data? By using a kernel older than 2.6.30 or using the non-default noauto_da_alloc mount option on 2.6.30 or later. (See mount(8) under Mount options for ext4, auto_da_alloc / noauto_da_alloc. Also the description for this commit)
From what I can tell, data is written before meta data by default for ext4 in recent kernels. So, while your data may still get eaten, it shouldn't be from metadata being written before data unless you have something like data=writeback,barrier=0 in your mount options.
Disclaimer: I'm not a file system engineer. I could be wrong. This is a "near as I can tell" type post.