Posted Mar 16, 2009 21:50 UTC (Mon) by quotemstr
In reply to: Wishful thinking
Parent article: Garrett: ext4, application expectations and power management
No, not really. I'm talking about rename being a write barrier, and not making rename flush data to disk at the instant it's called. The performance impact is minimal.
In a common case, the file being renamed has no dirty blocks, so no more work will be caused by writing the data blocks before the rename.
When the file being renamed has dirty blocks, these blocks will have to be written anyway. Forcing them out before, instead of after, the metadata will have a negligible impact on performance, especially since the elevator can combine these writes with other ones at the time of its choosing, not the application's.
And actually, forcing application developers to call fsync is worse for performance than making rename a write barrier. If rename isn't a write barrier, rename without fsync is dangerous, and therefore applications will add fsync. These fsync calls are worse for system performance than the rename being a write barrier: fsync forces out-of-order, non-coalesced disk flushes and vast increases in application latency. It also diminishes the effectiveness of laptop_mode --- forcing the disk to spin up.
Now, sometimes you need temporary files. But when do you go around renaming temporary files you don't intend to keep after dumping lots of data in them? If they have lots of data, the write ordering forced by the barrier won't matter much. If they have a little data, they're probably not going to get written out at all before they're unlinked. Either way, rename-as-write-barrier doesn't affect performance of temporary files.
Besides: if temporary files are a bottleneck, metadata journaling will hurt far more than the write barrier anyway. When you really, really want to optimize the performance of operations on temporary files, either use tmpfs or a freshly-created ext2 filesystem.
Making rename a write barrier is a performance win. Avoid fsync.
to post comments)