From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Kleikamp Subject: Re: [Ext2-devel] Re: [RFC] [PATCH] Generic mpage_writepage() support Date: Wed, 16 Feb 2005 15:46:36 -0600 Message-ID: <1108590396.8121.64.camel@localhost> References: <1108409415.20053.1278.camel@dyn318077bld.beaverton.ibm.com> <20050214134058.1402cfed.akpm@osdl.org> <1108430825.20053.1363.camel@dyn318077bld.beaverton.ibm.com> <20050214190556.07c4a0c9.akpm@osdl.org> <1108485967.20053.1438.camel@dyn318077bld.beaverton.ibm.com> <20050215095443.3e646401.akpm@osdl.org> <1108512141.20053.1490.camel@dyn318077bld.beaverton.ibm.com> <16915.12661.494053.290059@gargle.gargle.HOWL> <1108579020.20053.1513.camel@dyn318077bld.beaverton.ibm.com> <1108580964.8121.12.camel@localhost> <1108582105.20053.1517.camel@dyn318077bld.beaverton.ibm.com> <1108583034.8157.23.camel@localhost> <1108589898.20053.1522.camel@dyn318077bld.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Nikita Danilov , fsdevel , ext2-devel Return-path: Received: from e33.co.us.ibm.com ([32.97.110.131]:46316 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S262087AbVBPVqk (ORCPT ); Wed, 16 Feb 2005 16:46:40 -0500 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j1GLkc0D536064 for ; Wed, 16 Feb 2005 16:46:38 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1GLkcae365580 for ; Wed, 16 Feb 2005 14:46:38 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j1GLkasE030101 for ; Wed, 16 Feb 2005 14:46:37 -0700 To: Badari Pulavarty In-Reply-To: <1108589898.20053.1522.camel@dyn318077bld.beaverton.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-02-16 at 13:38 -0800, Badari Pulavarty wrote: > On Wed, 2005-02-16 at 11:43, Dave Kleikamp wrote: > > The patch I am working on will call mpage_writepages() for metadata, but > > will use my own writepage() rather than mpage_writepage(), and nothing > > in mpage_writepages() will use page->private. > > Okay, that will work. Basically, you plan to call mpage_writepages() > with NULL as get_block(). Isn't it ? Yes > > > > mpage.c already assumes page->private implies bufferheads, so it's not > > > > completely generic. Would implementing this as nobh_write_full_page, to > > > > complement block_write_full_page, make sense? > > > > > > I guess, it can be done. So to really deal with this, we need to come > > > up with generic writepage/writepages interfaces which doesn't deal > > > with bufferheads. > > > > I'm not sure how useful that would be. Are there any users of a > > non-bufferhead page->private that want to call a generic writepage(s)? > > In other words, if a generic function is sufficient, you probably > > wouldn't be using page->private anyway. > > This goes back to original question, is there a point in creating > new interfaces for writepage & writepages which doesn't assuming > page->private. So far, only users are ext2+nobh and JFS. But both > of them will not use page->private for anything else other than > bufferheads (if at all used). For both of these, the mpage_writepage() > I cooked up earlier would be good enough. I agree. I just think that nobh_write_full_page() would be a more consistent name than mpage_writepage(). > I guess, we will do it ONLY if someone really needs it. Agreed ... and I don't think anyone will need it. :^) > Thanks, > Badari Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center