All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaya Potter <spotter@cs.columbia.edu>
To: "John T. Kohl" <jtk@us.ibm.com>
Cc: nfsv4 <nfsv4@linux-nfs.org>, fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] Support for stackable file systems on top of nfs
Date: Thu, 10 Nov 2005 16:40:24 -0500	[thread overview]
Message-ID: <1131658825.8209.5.camel@localhost.localdomain> (raw)
In-Reply-To: <200511102135.jAALZlfS016100@sumu.lexma.ibm.com>

On Thu, 2005-11-10 at 16:35 -0500, John T. Kohl wrote:
> > 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.

I think you'd notice it on other file systems as well.  For instance, my
experience is that GFS doesn't play nice w/ stackable file systems that
try to stack on the a_ops.  On the other hand, it's ok if it just passes
all page cache operations directly down to the lower file system.
OCFS2, on the other hand, seems to play better w/ stacking on the a_ops.


  reply	other threads:[~2005-11-10 21:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-10 17:32 [RFC] Support for stackable file systems on top of nfs Dave Kleikamp
2005-11-10 20:07 ` Christoph Hellwig
2005-11-10 21:35   ` John T. Kohl
2005-11-10 21:40     ` Shaya Potter [this message]
2005-11-10 21:57       ` John T. Kohl
2005-11-10 21:50     ` Christoph Hellwig
2005-11-11  2:31     ` Trond Myklebust
2005-11-11  4:04       ` Trond Myklebust
2005-11-11 13:45         ` John T. Kohl
2005-11-11 15:27           ` Charles P. Wright
2005-11-11 17:38             ` John T. Kohl
2005-11-14 15:56       ` David Howells
2005-11-10 21:24 ` Trond Myklebust
2005-11-10 21:36   ` Shaya Potter
2005-11-10 22:18     ` Trond Myklebust
2005-11-10 22:27       ` Shaya Potter
2005-11-10 22:40         ` Trond Myklebust
2005-11-11  0:12           ` Bryan Henderson
2005-11-11  1:30             ` Brad Boyer
2005-11-11  2:06             ` Trond Myklebust
2005-11-11 18:18               ` Bryan Henderson
2005-11-11 19:22                 ` Trond Myklebust
2005-11-11 21:57                   ` Bryan Henderson
2005-11-11 22:41                     ` Trond Myklebust
2005-11-14 19:02                       ` Bryan Henderson
2005-11-11 16:40             ` Nikita Danilov
2005-11-11 18:45               ` Bryan Henderson
2005-11-11 19:31                 ` Nikita Danilov
2005-11-11 19:42                   ` Trond Myklebust
2005-11-11 23:13                   ` Bryan Henderson
  -- strict thread matches above, loose matches on Subject: below --
2005-11-14  0:44 Nikolai Joukov
2005-11-14 16:02 ` David Howells
2005-11-14 20:48   ` Erez Zadok
2005-11-14 21:13     ` John T. Kohl
2005-11-14 21:32       ` Jamie Lokier
2005-11-14 16:11 ` John T. Kohl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1131658825.8209.5.camel@localhost.localdomain \
    --to=spotter@cs.columbia.edu \
    --cc=jtk@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.