On Thu, Mar 15, 2007 at 05:36:42AM +0100, Nick Piggin wrote: > > Are we going to get rid of the file and intr arguments btw? I'm not sure > > intr is useful, and mapping is probably enough to get whatever we inside > > ->write_begin / ->write_end. > > Yeah, I was going to, but I had this version ready to go so decided > to leave them in at the last minute. We can definitely take them out > if people agree. > > However a side note about intr -- I wonder if it might be wise to > include a flags argument, in case we might want to add something like > that later? (definitely if we do keep intr, then it should be done as > a flag rather than its own int). I don't see a problem with having a flags argument. It could give us some flexibility in the future which would otherwise require a much bigger update. If we found out that we needed intr, it could just be a flag. > > One interesting side effect is that we no longer pass AOP_TRUNCATE_PAGE up a > > level. This gives callers less to deal with. And it means that ocfs2 doesn't > > have to use the ocfs2_*_lock_with_page() cluster lock variants in > > ocfs2_block_write_begin() because it can order cluster locks outside of the > > page lock there. > > OK that's very cool. I was hoping that would be the case. If GFS2 can > avoid that too, then we might be able to get rid of AOP_TRUNCATE_PAGE > handling from the legacy prepare/commit_write paths, which will make > them simpler. Yeah - so long as we're not taking a page fault between write_begin / write_end, there's no reason for the cluster locks to be taken and dropped within the individual callbacks, which means we can just take them in write_begin (where page lock ordering is possible) and hold them until write_end is called. > OK, well I'll add this to my queue for now, and post the full patchset > after incorporating feedback I've had so far, and doing more testing, > so people can actually apply them and boot kernels. Great, thanks - it just occured to me that I should be holding the clusters locks across the entire copy (as I point out above), so I'll have a slightly updated version of this patch for you soon :) --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@xxxxxxxxxx - 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
