| |||||||||||||
ext4 and data lossext4 and data lossPosted Mar 12, 2009 16:06 UTC (Thu) by JoeBuck (subscriber, #2330)In reply to: ext4 and data loss by ricwheeler Parent article: ext4 and data loss Try doing that on an ext3 system, and the performance of your system will go down significantly, to the point where users reject it. The fsync calls will cost you, big time. Firefox tried doing this and the Linux users nearly killed them.
(Log in to post comments)
ext4 and data loss Posted Mar 12, 2009 18:05 UTC (Thu) by cpeterso (guest, #305) [Link]
Why is fsync() on ext3 slower than fsync() on a non-journaled file system? Because fsync() has to update the journal on disk in addition to writing data and metadata?
ext3's slow fsync() Posted Mar 19, 2009 2:19 UTC (Thu) by xoddam (subscriber, #2322) [Link]
In default data=ordered mode, fsync(file) on ext3 is more-or-less equivalent to a sync of the entire filesystem. It forces all dirty file blocks to be flushed even those belonging to unrelated tasks, and the caller has to wait for the entire operation to complete. There is no clean way to flush the dirty blocks of only the desired file.
ext4 and data loss Posted Mar 12, 2009 20:27 UTC (Thu) by ricwheeler (subscriber, #4980) [Link]
You clearly don't want to blindly call fsync or use SYNC mode for normal operation.
Most applications have reasonable points where an fsync would make sense. If I remember correctly, firefox went a bit over the top trying to keep it internal database crash resistant.
For apps that really care about performance and data integrity both, you can try to batch operations - just like databases batch multiple transactions into a single commit.
File system equivalents would be when writing a bunch of files you can write them all without fsync, then go back and reopen/fsync them as a batch - try it, it will give you close to non-fsynced performance and give you a clear sense of when data is on disk safely.
|
|||||||||||||