From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Fasheh Subject: Re: [patch 2/5] fs: introduce new aops and infrastructure Date: Wed, 14 Mar 2007 23:11:46 -0700 Message-ID: <20070315061146.GD21942@ca-server1.us.oracle.com> References: <20070314112529.13798.35417.sendpatchset@linux.site> <20070314112540.13798.97719.sendpatchset@linux.site> <20070315041329.GB21942@ca-server1.us.oracle.com> <20070315043642.GF15069@wotan.suse.de> Reply-To: Mark Fasheh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux Filesystems , Linux Kernel , Christoph Hellwig , Andrew Morton To: Nick Piggin Return-path: Received: from rgminet01.oracle.com ([148.87.113.118]:21357 "EHLO rgminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422838AbXCOGMI (ORCPT ); Thu, 15 Mar 2007 02:12:08 -0400 Content-Disposition: inline In-Reply-To: <20070315043642.GF15069@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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@oracle.com