Re: recent nfs change causes autofs regression

Trond Myklebust
2007-08-31T19:04:09Z

On Fri, 2007-08-31 at 10:01 -0700, Linus Torvalds wrote:
>
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > The best I can do given the constraints appears to be to have the kernel
> > first look for a superblock that matches both the fsid and the
> > user-specified mount options, and then spawn off a new superblock if
> > that search fails.
>
> I think this is probably acceptable to get roughly the old behaviour, but
> I still think it's a bit stupid.
>
> What happens at "mount -o remount,..." time?
>
> The fact is, the whole "match the fsid and user mount options, and re-use
> the mount" sounds like it's trying to solve a problem that doesn't need
> solving. If the user really wants to duplicate the mount, he really should
> be using a a bind-mount instead.
>
> In other words, let's assume that the user has /some/nfs/mount mounted
> over NFS, and wants to re-mount it (or even just a subset of it) somewhere
> else, the sane thing to do is not to mount it again, but to just do
>
> mount --bind /some/nfs/mount/subdir /new/mount/place
>
> instead. That *guarantees* that the low-level filesystem uses the same
> flags, and it also means that things like re-mounting have sane and
> well-defined semantics, and will fail or succeed predictably.

I agree for the cases where you can use bind mounts, however you can't
always do that.

Consider the fairly common setup where /foo, /foo/a, /foo/b are all on
the same filesystem on the server, but only /foo/a and /foo/b are
exported.
There can be plenty of files that are contain hard links in both
directories, but because you cannot mount the parent, /foo, you will not
be able to ensure that these common files are cached to the same inode
(which they need to be).

IOW: with this scenario, you can't ensure that local posix semantics
hold (i.e. that if my client is the only user, then the filesystem will
behave as if it were a posix filesystem). That would be a major
regression.

> In contrast, if a user wants to create a new NFS mount, it really should
> be independent of the old one, because that's (a) what other systems do,
> and (b) also makes the semantics of re-mounting it with other flags be
> clear and unambiguous (ie the remount has nothing what-so-ever to do with
> the independent NFS mount).

(a) I'm not sure that is true: see (b).
(b) You gain remount clarity at the expense of local posix filesystem
correctness.

Trond