Re: fdatasync/barriers (was : [Bug 421482] Firefox 3 uses fsync excessively)

[jim owens <jowens@hp.com>]

Timothy Shimmin wrote:

>>>Bryan Henderson wrote:
>>
>>Must have been where he assumes we think of a barrier as something that 
>>causes a flush of the drive write cache.

In my case maybe I only assume the barrier will do that because
that is what I want to happen and I have not had time to
really dig into the docs and code.

>>If the idea is for fdatasync() to have that sync-to-platter function, 
>>fdatasync() should just tell the block layer to sync previously written 
>>data (now in the drive cache) to the platter; it has an interface for 
>>that, doesn't it?
>>
> 
> blkdev_issue_flush() do you mean?

My understanding (but I don't know this as fact) is:

Instead of a "flush-all-drive-cache" command, the  FS
should issue the proper barrier(s) to the blkdev layer
so it knows this set of data must sync-to-platter.

The key is "this set of data", not "all data".

The blkdev should know what the device supports for
caching and tagging I/Os and how to sync-to-platter
that "set of data".  If we are lucky, the device and
layers under the FS can sync-to-platter without a full
drive cache flush.  If not, then the device cache should
be flushed.

My further understanding is that some layers (and devices)
have bugs and don't sync-to-platter.  In my opinion those
are problems to fix or document so users can make the
right choices to protect their data.

jim