Re: which dentry a page belongs to

[Shaya Potter <spotter@cs.columbia.edu>]

On Fri, 2004-04-23 at 17:37 +0100, Christoph Hellwig wrote:
> 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.

so the mapping off the page struct will be null?

> > > 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.

so is that a yes to my understanding of "multiple dentries" i.e. a
single inode linked into multiple places in the fs.

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

so the vm_file part of vm_area_struct will be null?

> > > 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.

Yes, I know it's evil to do and would never be accepted into the kernel
proper, the question I'm trying to figure out if it it's possible (with
a stackable fs) to version files on write.  

via the write() interface it's easy (rename underlying dentry to new
name, create new dentry w/ old name, copy data from new name to old
name, with an underlying fs that supports a cow semantic can be pretty
quick, stacked fs also manages upper->lower name mappings) , 

via writepage() interface is what I'm trying to solve, without forcing a
open/close (as then could version on open, very easily), so that one
could essentialy ioctl() the fs, and all future initial writes cause a
version.  Without a stackale fs, but with a fs that supports versioning
this is easy, as just chain everything off the inode, trying to figure
out how to do this with a stackable fs.