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

["John T. Kohl" <jtk@us.ibm.com>]

> On Thu, Nov 10, 2005 at 11:32:22AM -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.
>> 
>> I am curious if there are any other stackable file systems that could
>> benefit from this.

Let me explain a bit more what's going on here.  MVFS would like to do
the same thing that CODA does.  In the file->mmap() operation, CODA and
MVFS want to set up paging operations to be handled by the backing store
inode.  See for example fs/coda/file.c:coda_file_mmap(), it sets
coda_inode->i_mapping = host_inode->i_mapping.

But this fails when host_inode is an NFS inode.  NFS assumes
that when it gets paging operations, it can look at the file pointer
passed to the address_space_operations' readpage function, and that file
pointer will be for an open NFS file.  If NFS is a backing store inode,
the file pointer is for the stacked file system's open file.

CODA certainly won't work today with NFS host inodes and mapped files.
I'm not surprised nobody noticed, since that seems like a poor way to
use CODA.  Using NFS backing store is a primary use case for ClearCase
MVFS, so we noticed.

-- 
John Kohl
Senior Software Engineer
Rational Software
IBM Software Group
Lexington, Massachusetts, USA
jtk@us.ibm.com

The opinions expressed in this message do not reflect the views of my
employer.