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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
