Let's go up a level. Why are you so focused on optimizing sync(2)? What's the use case where you anticipate applications using sync(2) or syncfs(2)? Or is this for the purpose of Tux3's benchmarketing? In practice, sync(2) as a data integrity mechanism is a bit heavyweight for most applications. In general the complaint with ext3 or ext4 is that fsync(2) is forcing a full filesystem-wide sync, and not just a sync specific to the file. System administrators use it sometimes[1], sometimes out of superstition, but how many applications actually use it? And why? [1] In fact, I've heard an argument that sync(2) should be optionally made privileged and only accessible to root, since there were cases where system administrators would login to a heavily loaded server as a non-privileged user, type "sync" out of reflex or habit, and the resulting huge amounts of I/O would blow the 99.9th percentile latency guarantees for all of the latency-sensitive services running on that server. If the goal is to optimize file system freeze operations, sure. But that's also not a common operation, so if it burns a little extra CPU time, it wouldn't cause me to think that it was a high priority issue. Decreasing the wall clock time for a file system freeze operation would probably be a far more interesting goal. Regards, - Ted -- 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
