linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@osdl.org
Cc: dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
	nfsv4@linux-nfs.org, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] VFS: Enable future NFS superblock sharing [try #3]
Date: Thu, 22 Jun 2006 15:23:58 +0100	[thread overview]
Message-ID: <20060622142358.10982.23148.stgit@warthog.cambridge.redhat.com> (raw)


The four patches in this set are:

 (1) A patch to fix a race between dentries being disposed of by memory
     shrinkage and being disposed of by unmounting.

 (2) A patch to pass the vfsmount record through to the get_sb() op, and have
     that fill it in rather than returning the superblock directly, so that
     the vfsmount root doesn't have to be the superblock root.

 (3) A patch to pass the dentry from the statfs() filename argument into the
     statfs() op instead of the superblock, so that the information returned
     can be based on the dentry.

 (4) A patch to have XFS make use of the dentry passed to statfs() to return
     per-project quota information rather than per-filesystem information.

The second and third patches are a precursor to the NFS superblock sharing
patches.  The NFS superblock sharing patches group NFS files together into
superblocks by {server, protocol, FSID}.

Ideally we'd represent each FSID tree retrieved from the server as a single
tree in the client, rooted at the root of the FSID tree.  However, things are
much more messy than that for two reasons:

 (1) We may jump directly into the middle of a tree (consider mountd), and we
     may not be able to access the common root of a tree on the server.

     This means we may know about several subtrees of a particular filesystem
     on the server, but not be able to get the bits connecting them.  Consider
     /home: the automounter might mount various users' home directories, but it
     may not actually be able to mount the directory in which they live.

 (2) We can't simply assume that the hidden common bit of the paths forms a
     real tree.  Symbolic links on the server may distort our perception of
     reality, and if the common part suddenly becomes visible, we may find that
     the dentry tree we've constructed is out of shape.

So what we want to do with NFS is have the ability to have separate trees
within one superblock, and to splice the root of one as a branch on another
when we find a connection.

The getsb patch permits the get_sb() op to return an arbitrary root for a
superblock, allowing multiple trees to be set up within the superblock, or
permitting a subtree to be returned (similar to mount --bind).

The statfs patch permits the statfs() op to find out which bit of the tree is
being probed.  In the NFS case, this is because the actual root dentry is a
dummy that is never actually used (since we aren't necessarily sure of what the
root actually is).  For FUSE this might be because different dentries map to
different data sources.

[try #3] is updated to 2.6.17-git4 and now includes an extra patch to permit
XFS to show per-project quota information via statfs(), depending on which
project the dentry specified as the base for statfs() belongs to.

The first patch (fix-dcache-race-during-umount in -mm) is now a prerequisite
to the others.

David

             reply	other threads:[~2006-06-22 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-22 14:23 David Howells [this message]
2006-06-22 14:24 ` [PATCH 1/4] Fix dcache race during umount [try #3] David Howells
2006-06-22 14:24 ` [PATCH 2/4] VFS: Permit filesystem to override root dentry on mount " David Howells
2006-06-22 14:24 ` [PATCH 3/4] VFS: Permit filesystem to perform statfs with a known root dentry " David Howells
2006-06-22 14:24 ` [PATCH 4/4] XFS: Use the dentry passed to statfs() to limit the scope of the results " David Howells

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=20060622142358.10982.23148.stgit@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    --cc=torvalds@osdl.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).