Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]

Ian Kent
2006-08-22T02:05:19Z

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