To view parent comment, click here.
To read all comments associated with this story, please click here.
If ext4's current default config is truly robust, that's great. I'm very excited about ext4. But I would be interested in how you would relate your observations to the quote, below, from Ted's blog. If you could satisfactorily resolve that discrepancy, then I would probably be satisfied. Even happy. :-)
=======
Another solution is a set of patches to ext4 that has been queued for 2.6.30 merge window. These three patches (with git id’s bf1b69c0, f32b730a, and 8411e347) will cause a file to have any delayed allocation blocks to be allocated immediately when a file is replaced. This gets done for files which were truncated using ftruncate() or opened via O_TRUNC when the file is closed, and when a file is renamed on top of an existing file. This solves the most annoying set of problems where an existing file gets rewritten, and thanks to the delayed allocation semantics, that existing file gets replaced with a zero-length file. However, it will not solve the problem for newly created files, of course, which would have delayed allocation semantics.
=======
The bolding, above, is mine, of course.
Edited 2009-03-31 23:07 UTC





Member since:
2005-07-24
The patches keep previously existing files from ending up truncated after a crash. But new files that were created less then 60 seconds before the crash will still show up as 0 length files. Data and metadata still have a large window of time in which they are out of sync.
In contrast, with ext3, the files would either exist, or they would not. If the crash occurred at least 5 seconds after the write, they would exist and contain the expected data. If the crash occurred less than five seconds after, this might still be the case. But in the worst case, the files are not written at all. In all cases, ext3 would maintain the disk in either its state before the completed write, or its state afterwards, data and metadata remaining in sync.
You say that I should just use ext3. But that's not the point. Sacrificing Linux's reputation for reliability for the sake of better benchmark numbers is simply not a good trade.