Re: recent nfs change causes autofs regression

[Trond Myklebust <trond.myklebust@fys.uio.no>]

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

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