From mboxrd@z Thu Jan 1 00:00:00 1970 From: Badari Pulavarty Subject: Re: [Ext2-devel] Re: [RFC] [PATCH] Generic mpage_writepage() support Date: 16 Feb 2005 13:38:19 -0800 Message-ID: <1108589898.20053.1522.camel@dyn318077bld.beaverton.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Nikita Danilov , fsdevel , ext2-devel Received: from e5.ny.us.ibm.com ([32.97.182.145]:56254 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S262066AbVBPVhq (ORCPT ); Wed, 16 Feb 2005 16:37:46 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1GLbjeO020647 for ; Wed, 16 Feb 2005 16:37:45 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1GLbj40280156 for ; Wed, 16 Feb 2005 16:37:45 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1GLbj2E007943 for ; Wed, 16 Feb 2005 16:37:45 -0500 To: Dave Kleikamp In-Reply-To: <1108583034.8157.23.camel@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-02-16 at 11:43, Dave Kleikamp wrote: > On Wed, 2005-02-16 at 11:28 -0800, Badari Pulavarty wrote: > > On Wed, 2005-02-16 at 11:09, Dave Kleikamp wrote: > > > On Wed, 2005-02-16 at 10:37 -0800, Badari Pulavarty wrote: > > > > > > > Yes. page->private is assumed for the bufferhead usage. Do you really > > > > need for handling page->private for non-bufferhead usage ? > > > > > > For what it's worth, I'm working on some changes to jfs that will use > > > page->private for non-bufferhead usage for metadata, but I won't be > > > using a generic writepage, so it's not an issue for me. > > > > Nope. it would be an issue for you, since jfs uses mpage_writepages() > > which uses the same code - which thinks page->private as bufferhead. > > 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 ? > For normal data, page->private, if used at all, will be bufferheads. Good. > > > > > > > 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 guess, we will do it ONLY if someone really needs it. Thanks, Badari