[PATCH 0/2] VFS: Enable future NFS superblock sharing [try #2]

[David Howells]

These two 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 #2] is updated to 2.6.17-git2.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/