Alexander Viro wrote:
>
> On Wed, 15 Nov 2000, Rik van Riel wrote:
>
> > On Tue, 14 Nov 2000, Alexander Viro wrote:
> > > On Tue, 14 Nov 2000, Daniel Phillips wrote:
> > >
> > > > After quite a lot of grepping in 2.4.0-test10 I was unable to find any
> > > > places where address_mapping->host is not (struct inode *) - are there
> > > > any?
> > >
> > > Currently - none. As soon as block devices go to pagecache we'll
> > > have such beasts (you need one address_space for all inodes with
> > > given major:minor, so ->host can't point to any of them).
> >
> > So how do we find a certain inode:offset page in
> > the page cache? I hope we won't have to make the
> > page_struct even bigger to make that possible...
>
> inode->i_mapping, then convert offset to page number and search the hash
> chain. Why?
The conversion from page back to inode needs the ->host field to be an
inode, reliably. Why would we want to do such a conversion? It's when
the mm runs low on memory and wants to flush a dirty, inactive page.
When it finds one, it looks at the page->mapping field and decides that
the page must be a page cache page, after rejecting a few other
possibilities. Now it wants to notify the filesystem that owns the page
cache page that it should flush that page so the page can be recovered.
(If the filesystem *can't* flush that page it should try to make an
equally good substitute choice, but that's another story.) At this
point we need to be to get the page's inode efficiently - it's sitting
there in the ->host field, no problem, except now you're talking about
putting other things there with no way to know what they are. Do you
have another suggestion on how to find the page's inode?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
