Re: which dentry a page belongs to

[Christoph Hellwig <hch@infradead.org>]

On Fri, Apr 23, 2004 at 11:42:19AM -0400, Shaya Potter wrote:
> > i_mmap and i_mmap_shared are lists.  They can both be empty, or both
> > non-empty.  A page can be mapped shared *and* non-shared at the same
> > time.  A page might not be mapped at all.
> 
> yes, they can be empty for "generic" pages, but I'm looking at a
> specific case of file system pages, so they shouldn't be empty.  i.e.
> otherwise my fs's writepage() shouldn't be called, I would think.

in 2.4 writepage is always the result of data dirtied by mmap.  In 2.6 it's
also for use for data dirtied by write.  Even in 2.4 there's no gurantee
the mapping that dirtied the page still exists when the page is written out
by the VM.

> > It is possible to find multiple dentries which are currently being
> > used to map a page.
> 
> a single page can have multiple dentries?  but it has only one inode?

Yes.

> (i.e. host) So I can imagine if the single inode is linked in multiple
> places (for my purposes I don't care about that directly) but can it
> really have multiple inodes?

It can't have multiple inodes.

> > It's also possible to find no dentries at all.
> 
> even if in my fs's writepage() function?

Yes.

> > Your question is extremely ill-formed.  What do you mean by "the
> > dentry corresponding to a page"?  What do you want the value for?
> 
> When my writepage() is called, I want to be able to possibly do dentry
> based operations (rename, d_path....) to be told what files are actually
> getting written to via writepage() (as opposed to the file system's
> write() functionality).

You can't do that.