Subject: Re: Extension of fsync_range() to permit forcing disk cache flushing
To: Bill Studenmund <>
From: Manuel Bouyer <>
List: tech-kern
Date: 12/17/2004 10:08:48
On Thu, Dec 16, 2004 at 12:16:09PM -0800, Bill Studenmund wrote:
> I have an application that wants to be able to know that certain writes 
> have been forced to permanent storage - that they aren't still sitting in 
> the disk's write cache. This idea is similar to the current thread about 
> wd and write caches, except here we're talking about userland wanting to 
> request the flushing.
> After discussing this with some developers, the best solution seems to be 
> to add a flag to fsync_range() to force this behavior. Then pass a flag 
> down to VOP_FSYNC() to trigger a disk cache flush after the other update 
> steps happen.
> The current implementation just flushes the whole disk cache. Future 
> implementations may be selective and issue finer-grained cache flushes.
> Thoughts?

I'm not really happy with this. IMHO this should be the default behavior of
fsync(). A programmer using fsync in his software uses it to make use data
is on stable storage.
Maybe in some cases turning off the write back cache isn't the best option,
what about a per-mount option to control the behavior of fsync() on
a mount-point basis ?
Anyway I don't think we should need an extra, non-standard flag to fsync
to get what should be the default behavior.
Also note that you may not want to flush the cache in all cases. For example,
with SCSI tagged queuing, a write barrier would be enouth to meet this

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference