Re: [RFC] [PATCH] Generic mpage_writepage() support

[Dave Kleikamp <shaggy@austin.ibm.com>]

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.

For normal data, page->private, if used at all, will be bufferheads.

> >
> > 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.
-- 
David Kleikamp
IBM Linux Technology Center



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click