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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
