> 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. But that's not what a barrier does. In fact, I'm pretty sure no disk device provides the facilities to make that possible. A barrier doesn't say any particular data must sync-to-platter. What it says is that writes requested _after_ now should _not_ sync-to-platter until those requested before have done so. It could still be arbitrarily long before the data previously written gets to the platter. A pure barrier doesn't even give the requester any way to know when the data has hit the platter; its essential purpose is to make it so the requester doesn't have to know; it's a way for the requester to say, "I would have waited here for all previous writes to harden before starting any more; so that I don't have to suffer the slowdown of a dry queue, please do that ordering _for_ me while I continue to feed you requests." But the Linux implementation does provide notification when the barrier moves through, so a requester could abuse it as a way to synchronize some other activity with his data hitting the platter. For fdatasync() purposes, the fact that blkdev_issue_flush() syncs all data previously written, even though the user requires only one file's data to be synced, is a problem. Maybe that's the best reason not to do it. At least not unconditionally. A barrier would have that same problem while simultaneously needlessly delaying later writes. > 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. Those aren't bugs. They're conscious design choices, so the worst you can say about them is they are design defects. The designer decided that the user would be more upset by constant slowness than by exposure to data loss in certain situations. Yes, even though the user's program or OS explicitly requested sync-to-platter. But I agree the behavior should be documented -- probably in every listing of the device's specifications. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems -- 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
