[lkml]   [2007]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: recent nfs change causes autofs regression
    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
    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

    > 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-31 21:07    [W:0.029 / U:5.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site