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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
