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

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

>>>>> "Charles" == Charles P Wright <cwright@cs.sunysb.edu> writes:

Charles> On Fri, 2005-11-11 at 08:45 -0500, John T. Kohl wrote:
>> Other than i_mapping/f_mapping, I don't think it's possible right now
>> for stacking file systems to handle the address_space operations in our
>> layer *and* share the same pages with the backing-store, since the struct
>> pages are attached to the address space via file->f_mapping.
Charles> At Stony Brook, we've come across similar problems.  It is relatively
Charles> easy to double cache, but inefficient.  It is also relatively easy to
Charles> single-cache, but then you don't get to intercept any of these
Charles> interesting operations.  Getting both at once is tricky.

We currently do single-caching, by passing on the mmap operation to the
backing store (swapping in the backing store file for vma->vm_file).
(We do the equivalent in our MVFS built for vnode kernels.)  Swapping
the vm file is mostly workable, but we do have to be a bit too
knowledgable about the innards of file mapping and do some things to
accomodate the actions taken after fop->mmap is called.

However, it does mean that things like /proc/<pid>/exe show the
backing-store file name not the upper-level name.  That screws up some
programs like Java which use /proc/self/exe to find their environment,
since our backing-store directory layout is nothing like the upper-level
layout.

-- 
John Kohl
Senior Software Engineer - Rational Software - IBM Software Group
Lexington, Massachusetts, USA
jtk@us.ibm.com
<http://www.ibm.com/software/rational/>