Subject: Re: Extension of fsync_range() to permit forcing disk cache flushing
To: None <firstname.lastname@example.org>
From: J Chapman Flack <email@example.com>
Date: 12/16/2004 17:16:48
> > belief when the man page says "causes all modified data ... to be written
> > to permanent storage." It seems more conservative to make sure that code
> Note: I think you missed a word in there, and that word is important.
> Either that or we updated the man page. My man page says "permanent
> storage device." fsync and fsync_range DO ensure the data made it to the
The word's in the first paragraph, not the third, from which my quote was
drawn. But I don't really agree it's important - if we point to that word
as our excuse for not getting bits on a platter when the programmer thought
she told us to, it's an excuse with a hyperlegalistic quality: "HO HO!
YOU thought we meant getting the bits reliably recorded, but if you look
REALLY CLOSELY at our wording, you see we only said to a DEVICE."
If we really mean the manual page to say "this does not ensure your bits
get to the platter from a storage device's write-back cache" then the page
should say exactly that. That still doesn't help code that was already
written before the man page said exactly that.
> If instead we force fsync() and fsync_range() to always clear the cache,
> we prevent admins from being able to decide what is safe-enough.
> Also, you're implicitly assuming that disks don't fail. If an admin has
> taken steps, either in configuration or product choice (good UPS or RAID
> box w/ battery backup for cache), to ensure that writing to the disk drive
> is as good as writing to the media, why penalize him or her by forcing
> cache flushing. And since disks fail (even in RAID), all we have to do is
But I don't mean to force anyone, and I didn't assume anything about
drives failing. I was advocating for a default fsync behavior that
upholds the contract I believe most programmers expect of fsync, and
that is supported by the non-hyperlegalistic, plain-sense reading of
our own and other unices' man pages; the developer or admin who is
certain a more relaxed semantics will work for a given job can be the
one who turns the knob to relax it.