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
next 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).