On Mon, Dec 22, 2008 at 01:56:22PM +0100, Christoph Hellwig wrote: > On Mon, Dec 22, 2008 at 01:35:34PM +0100, Nick Piggin wrote: > > Seems like an improvement.. I've wanted to know, though, what do > > we need i_mutex for? Is it just convention, or is there some good > > reason to have it in generic code? > > At least XFS doesn't need it. Same for the filemap_fdatawrite / > filemap_fdatawait which at least for filesystems that want to provide > integrity guarantees is in the wrong place. > > This patch is a first one out my work to refactor fsync, and I'm trying > to feed it to mainline in pieces. The next one will be to make sure OK, I gues that's fair enough. The generic pagecache layer as you know shouldn't require i_mutex... so long as you have a plan in mind to decouple that requirement from generic code I'm happy with it. > nfsd always has a struct file available when calling fsync, but I need > to do some extensive benchmarking. After that we can change the > fsync prototype to drop the dentry paramters, and move the > filemap_fdatawrite / filemap_fdatawait aswell as the i_mutex locking > into the actual methods. They all sound like good steps I think. Well I have no really helpful comments for your RFC except that I think it is a good idea. Probably some filesystem-side people should have a look at it... -- 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
