lkml.org 
[lkml]   [2006]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
    On Mon, 21 Aug 2006, David Howells wrote:

    OK. I think I get it now.
    Thanks for your patience.

    > Ian Kent <raven@themaw.net> wrote:
    >
    > > > But does it _matter_ that the thing is mounted or dismounted as a unit? And
    > > > if so, why?
    > >
    > > Yes with autofs version 4, because of the nesting of mounts which also
    > > introduces issues with expiration.
    >
    > The NFS client's automounting facilities handle automatic expiration and
    > implicit recursive unmounting of xdev submounts.

    Very cool.

    I guess I'm not concerned about what the expire timeout is for such trees
    either as it's not my problem.

    I'll have to play around with these a bit to work out how I can recognize
    them in the export list. Hopefully it will be straight forward.

    >
    > This should now be left to the NFS client.

    Yep.

    >
    > > Not updating the mtab will be a problem for me also and possibly for
    > > users that expect to see mounts in it.
    >
    > ln -sf /proc/mounts /etc/mtab
    >
    > > The "/net" functionality is a standard, expected automounter function.
    >
    > Whilst that may be true, it doesn't prohibit working with the NFS clients
    > automounting capabilities.

    Yep.

    Again, not my problem if I treat fsid filesets as the automount unit.

    >
    > > > Note that rather than manually mounting the submounts, you could just open
    > > > and close those directories as that should cause them to automount -
    > > > though the xdev mountpoints will expire and become automatically unmounted
    > > > after a certain period.
    > >
    > > The xdev (assume you mean NFSv4 submounts) mounts will be the area I need
    > > to work on, for sure.
    >
    > I mean NFSv2, NFSv3 and NFSv4 submounts that cross FSID, but remain on the
    > same server.
    >
    > > I don't quite understand the "open will cause the automount" for NFS
    > > version < 4.
    >
    > Opening the directory will cause its follow_link() op to be invoked, which
    > will cause an automount if one hasn't already happened. Obviously, if the
    > automount has taken place, the lower directory won't be seen for the follow to
    > take place.

    Yep. But also not my problem as user activity will make this happen
    automagically.

    >
    > > The automounter calls mount(8) when it gets a packet from the
    > > autofs[4] kernel module due to an access.
    >
    > The automounter must mount the root of any tree, yes; but xdev subtrees should
    > now be left to the NFS client to mount, which can be triggered by stat'ing the
    > mountpoint - admittedly, if you can reach it without a security error.
    >
    > If you do get a security error, and attempt to build the directories anyway,
    > you run the risk of constructing a false image of the remote share as you
    > can't tell symlinks from directories, and run the risk of creating invalid
    > dentries locally because you can't determine the attributes of the remote
    > object.

    Yep. No use in stepping on NFSs toes when he just wants to make my life
    easier for me.

    Ian

    -
    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/

    \
     
     \ /
      Last update: 2006-08-22 04:11    [W:2.119 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site