Messages in this thread | | | Date | Wed, 25 Mar 2009 16:25:42 -0400 | From | Jeff Garzik <> | Subject | Re: Linux 2.6.29 |
| |
Jens Axboe wrote: > On Wed, Mar 25 2009, Jeff Garzik wrote: >> Stating "fsync already does that" borders on false, because that assumes >> (a) the user has a fs that supports barriers >> (b) the user is actually aware of a 'barriers' mount option and what it >> means >> (c) the user has turned on an option normally defaulted to off. >> >> Or in other words, it pretty much never happens. > > That is true, except if you use xfs/ext4. And this discussion is fine, > as was the one a few months back that got ext4 to enable barriers by > default. If I had submitted patches to do that back in 2001/2 when the > barrier stuff was written, I would have been shot for introducing such a > slow down. After people found out that it just wasn't something silly, > then you have a way to enable it. > > I'd still wager that most people would rather have a 'good enough > fsync' on their desktops than incur the penalty of barriers or write > through caching. I know I do.
That's a strawman argument: The choice is not between "good enough fsync" and full use of barriers / write-through caching, at all.
It is clearly possible to implement an fsync(2) that causes FLUSH CACHE to be issued, without adding full barrier support to a filesystem. It is likely doable to avoid touching per-filesystem code at all, if we issue the flush from a generic fsync(2) code path in the kernel.
Thus, you have a "third way": fsync(2) gives the guarantee it is supposed to, but you do not take the full performance hit of barriers-all-the-time.
Remember, fsync(2) means that the user _expects_ a performance hit.
And they took the extra step to call fsync(2) because they want a guarantee, not a lie.
Jeff
| |