On Sun, Jun 18, 2000 at 02:41:19AM -0400, Alexander Viro wrote:
>
>
> On 17 Jun 2000, Juan J. Quintela wrote:
>
> > >>>>> "al" == Alexander Viro <aviro@redhat.com> writes:
> >
> > Hi
> >
> > al> * adds a new method to address_space_operations: void detach_page(page).
> > al> Meaning: do all work necessary to make page droppable. For block-based
> > al> filesystems it's block_destroy_buffers(). For ramfs - ClearPageDirty().
> > al> It is used by truncate_complete_page() and truncate_all_inode_pages() -
> > al> i.e. whenever we are getting rid of a page due to truncate() or final
> > al> iput() after unlink().
> >
> > Al, do you see any problem to my previous patch to the list about
> > including ClearPageDirty(page) in remove_inode_page()???
>
> Erm... Look what block_destroy_buffers() does: it notifies the underlying
> layer that page is going away, so it must finish whatever it was doing
> with the page, do whatever it takes to make it clean and fsck off. It
> makes sense for _all_ filesystems. For block-based ones it's
> block_destroy_buffers(), for things like ramfs it's "you want it clean -
> get it", for something network-based it may (or not) be "cancel pending
> writes", etc. IOW, I think that test for (page->buffers) is wrong - it
> just reflects the fact that for all block-based ones we have the same
> method. Letting the address_space decide what should be done with such
> pages is, IMO, the Right Thing(tm).
The PG_dirty bit is cleared in add_to_swap_cache() and
__add_to_page_cache() so this is kind of redundant, but the
detach_page hook is good news in general.
I have a patch which adds page/inode/dentry limits to ramfs. It adds a
'removepage' hook to address_space_operations (called from
remove_page_from_inode_queue()) in order to keep track of the number
of pages currently in use. I think this is more-or-less equivalent to
your detach page.
I meant to send the patch to fsdevel a week or two ago, but I managed
to botch the address and haven't got around to resending yet. I might
wait till detach_page goes in, then I won't need to touch any files
except fs/ramfs/inode.c and Documentation/filesystems/ramfs.txt (which
I add).
-- David Gibson, Technical Support Engineer, Linuxcare, Inc. +61 2 6262 8990 dgibson@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:16 EST