Re: [RFC] Support for stackable file systems on top of nfs

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

On Thu, 2005-11-10 at 16:24 -0500, Trond Myklebust wrote:
> On Thu, 2005-11-10 at 11:32 -0600, Dave Kleikamp wrote:
> > The following patch allows stackable file systems, such as ClearCase's
> > mvfs, to run atop nfs.  mvfs has it's own file and inode structures, but
> > points its inode->i_mapping to the lower file system's mapping.  This
> > causes problems when nfs's address space operations try to extract the
> > open context from file->private_data.
> > 
> > The patch adds a small overhead of checking the file structure to see if
> > it contains an inode that is not the mapping's host.
> 
> NACK
> 
> This is a fundamentally flawed approach. The nfs_find_open_context() is
> designed for the mmap() case were you have a valid vm_area_struct, that
> has a "struct file" with a valid NFS open context attached to it.
> Existence of the file is guaranteed, but the readpage() and writepage()
> interfaces don't actually pass the struct file down to the filesystem.
> 
> This is clearly not the case here.
> 
> If you want to make mvfs work correctly with NFS, then have it set up a
> valid NFS struct file, and use that file with the NFS functions.
> Anything else is borken.

from my experiences with stackable file systems, I'm not sure the above
is totally correct.  i.e. vm_area_structs only around while a process is
in use.  Once a process exits, the file and vm_area_struct go away.

now imagine if you do a mmap shared write, don't sync and just exit the
program.  Some time later the kernel will kick in, call writepage() and
write the page to disk, but your above "guarantees" are no longer
around.