[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, 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.

    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).


    This is why I think "nosharecache" should just be the default, because
    that's the behaviour that simply does not have any subtle issues. The
    *special* case should be the "sharecache" case, and 99% of the time that
    one should likely be done with a "--bind" mount.

    (I don't really see the point of _ever_ doing anything but a bind mount,
    but maybe there are reasons to try to share at a NFS layer that I don't
    really see)

    > The attached patch does just that.

    Hua, does this fix things for you? If it gets rid of the regression, I can
    certainly live with it, but as per above, I don't really think this makes
    much sense in the "bigger picture" kind of thing.

    > Finally, for the record: I still feel very uncomfortable about not being
    > able to report the state of the client setup back to the sysadmin.
    > AFAIK, the only way to do so is to stat the mountpoints, and compare the
    > device ids.

    Well, not only don't I see that as being horribly wrong, I actually think
    that the sysadmin should know what his mount setup is, even without having
    to ask. But since he *can* ask, using easy and standard interfaces, I
    don't really see what the problem really is.

    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 19:05    [W:0.022 / U:2.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site