From: Shaya Potter <spotter@cs.columbia.edu>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: fsdevel <linux-fsdevel@vger.kernel.org>,
nfsv4 <nfsv4@linux-nfs.org>,
Dave Kleikamp <shaggy@austin.ibm.com>
Subject: Re: [RFC] Support for stackable file systems on top of nfs
Date: Thu, 10 Nov 2005 17:27:36 -0500 [thread overview]
Message-ID: <1131661656.8209.11.camel@localhost.localdomain> (raw)
In-Reply-To: <1131661094.8804.17.camel@lade.trondhjem.org>
On Thu, 2005-11-10 at 17:18 -0500, Trond Myklebust wrote:
> On Thu, 2005-11-10 at 16:36 -0500, Shaya Potter wrote:
> > 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.
>
> ...calling file->f_ops->release() in the process. Guess what happens
> there?
from my experience, writepage is called signficantly after a process is
gone. I've seen this via instrumenting writepage() in using stackable
file systems and a simple program that maps a file, modifies it, and
then exits. the kernel hit the writepage() function 30 seconds or so
after the process existed.
ext2_release_file just does a ext2_discard_prealloc, which has nothing
to do with written data.
In looking at nfs, nfs_file_release does write out the data by calling
filemap_fdatawrite(), but it seems somewhat unique in that regard, but I
guess we are talking about NFS here. :)
next prev parent reply other threads:[~2005-11-10 22:27 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
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 [this message]
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=1131661656.8209.11.camel@localhost.localdomain \
--to=spotter@cs.columbia.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=shaggy@austin.ibm.com \
--cc=trond.myklebust@fys.uio.no \
/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.