On Thu, Feb 08, 2007 at 04:38:01PM -0800, Mark Fasheh wrote: > On Thu, Feb 08, 2007 at 02:07:15PM +0100, Nick Piggin wrote: > > The problem is that the existing aops interface is crap. "correct, fast, > > compatible -- choose any 2" > > Agreed. There's lots of problems with the interface (imho), but my biggest > two issues are the page lock being held on ->prepare_write() / > ->commit_write() and the fact that the file system only sees the write one > page at a time > > > > So I have finally finished a first slightly-working draft of my new aops > > op (perform_write) proposal. I would be interested to hear comments about > > it. Most of my issues and concerns are in the patch headers themselves, > > so reply to them. > > I like ->perform_write(). It allows the file system to make re-use of the > checks in the generic write path, but gives a maximum amount of information > about the overall operation to be done. There's an added advantage in that > some file systems (ocfs2 is one of these) want to be more careful about > ordering page locks, which should be much easier with it. Yeah, if possible I like a range based interface rather than page based. As you say it gives the most information with the least constraints. > If this goes in, it could probably be helpful to me in some of the code I'm > currently writing which needs to be better about page lock / cluster lock > ordering and wants to see as much of the (allocating) writes as possible. I think it would be important to have a non trivial user of this new API before it goes into mainline. It would be great if you could look at using it, after it passes some review. Thanks, Nick - 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
