On Mon, Apr 16, 2007 at 05:19:32PM -0700, Mark Fasheh wrote: > On Thu, Apr 12, 2007 at 06:48:52AM +0200, Nick Piggin wrote: > > http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/ > > > > 2.6.21-rc6-new-aops* > > > > New aops patchset against 2.6.21-rc6. > > Ok, here's an ocfs2 patch against -mm / ocfs2.git ALL. It makes use of the > context back pointer to store information related to the write which the vfs > normally doesn't know about. Most importantly this is an array of zero'd > pages which might have to be written out for an allocating write. Of note is > that I also stick the journal handle on there. Ocfs2 could use > current->journal_info for that, but I think it's much cleaner to just pass > that around as a file system specific context. > > I tested this on a couple nodes and things seem to be running smoothly. Thanks Mark, I'll let you know if I have any problems with it. I guess the plan will be to rebase the new-aops patchset on -mm at some point soon, but we'll have to work out where in -mm Andrew wants it and other details like when to merge it... I'll try to bring Andrew into the public discussion for that. > A couple of notes: > > * The ocfs2 write context is probably a bit big. I'm much more concerned > with readability though as Ocfs2 has much more baggage to carry around > than other file systems. I guess your high performance write path could be ->perform_write in future anyway, which could keep that on the stack. I'll possibly omit the perform_write stuff in the first -mm merge, so that we can get the basics reviewed and working, and exercise the write_begin/write_end paths well first. The bulk interface will come, and I think it is in much better shape to be implemented after various things like iov iterator, the offset,length based API rather than page based. Whether we introduce it by moving the iov_iter and some of the more generic checks further down the stack first, or introduce it as ->perform_write aop first probably doesn't matter so much: the conversion between one and the other is trivial compared to implementing it in the first place, so nobody should worry that we haven't sorted this out yet. > > * A ton of code was deleted :) The patch adds a bunch too, but that's mostly > getting the old stuff to flow with ->write_begin. Some assumptions about > the size of the write that were made with my previous implemenation were > no longer true (this is good). > > * I could probably clean this up some more, but I'd be fine if the patch > went upstream as-is. Diff seems to have mangled this patch file enough > that it's probably much easier to read once applied. OK, thanks again. I'll ping you again in the next couple of days to discuss merge plans. 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
