On Thu, Mar 13, 2014 at 11:36:35AM +1100, Dave Chinner wrote: > > Folks on linux-fsdevel, any objections if I carry this patch in the > > ext4 tree? I don't think it should cause problems for other file > > systems, since any file system that tries to rely on the implied > > syncfs() is going to be subject to races, but it might make such a > > race condition bug much more visible... > > IMO, I think that you should be looking to fix ext4 syncfs issues, > not changing the VFS behaviour that might cause subtle and unnoticed > problems for other filesystems. We should not be moving data > inegrity operations without first auditing of all the filesystem > remount operations for issues. The issue is that it's forcing a CACHE FLUSH if we don't need to force a journal commit, since it's possible that data writes could have been sent to the disk without modifying fs metadata that would require a commit. So arguably what we're doing with ext4 is _correct_, where as with ext3 we would simply not calling blkdev_issue_barrier() in that situation. The issue is that if userspace executes a no-op remount, there shouldn't be a reason to call sync_filesystem() at all. But I'm also not so sure that I should be that solicitous of a workload where someone is calling thousands and thousands of no-op remounts..... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
