That helps one case, yes, but what about a superset? What about two sets that
might intersect but for which you don't have the common root to hand? The
current NFS code deals with all these problems by attempting to share the
dentry sets. Superblocks can now have multiple roots and we graft trees
together automatically when we discover one is a subset of another.
The case I came up with was this:
mount home:/home/fred /home/fred
mount home:/home/jim /home/jim
To effect these, the NFS mount process looks up "/home/fred" or "/home/jim"
directly rather than looking up "/" and path walking. However, the NFS client
in the kernel may note that both Fred's and Jim's home directories reside on
the same NFS volume. You cannot use a bind mount here because there's nothing
to bind from.
Then, should, say, this happen:
mount home:/home /mnt
You'll probably end up with three roots in the NFS superblock. Following with
an ls of /home, say, would then populate the dentries for /home - including
those for fred and jim, and the code would splice in the dentried now rooted at
/home/fred and /home/jim.
You can't do that with bind mounts as far as I know because I don't believe
that you can go up the tree (rootwards) from the apparent root of a vfsmount.
So bind mounts aren't quite it for this problem, and in any case your
suggestion of:
mount --bind /some/nfs/mount/subdir /new/mount/place
doesn't help with the automounter case particularly well. The automounter
*could* probe to see if the server stuff is common with an already existing
mount, but there would then be a race, and it doesn't help with the homedir
example I gave above either.
You might think "well, start by mounting '/' somewhere and then bind mounting
subdirs of it", but that doesn't work if you can't mount "/" or "/home", and
might go spectacularly wrong if the server has a symlink in the path that you
can't see.
Yeah, that's probably necessary, if annoying. However, local caching can
enable sharing or make it a prerequisite option.
The reason I added all this NFS superblock sharing is so that I could implement
on-disk local caching much more easily. If, for instance, two netfs inodes
aren't shared, but their "index keys" say they should use the same piece of
cache then all sorts of fun ensues from the disjoint cache coherency.
Even working out that two inodes are using the same piece of cache isn't
trivial (though it seems like it ought to be).
David
-
