Re: [PATCH] NFS: Replace null dentries that appear in readdir's list[try #2]
From: Ian Kent
Date: Mon Aug 21 2006 - 22:09:25 EST
On Mon, 21 Aug 2006, David Howells wrote:
OK. I think I get it now.
Thanks for your patience.
> Ian Kent <raven@xxxxxxxxxx> 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.
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.
> > 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.
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
> > The automounter calls mount(8) when it gets a packet from the
> > autofs 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
Yep. No use in stepping on NFSs toes when he just wants to make my life
easier for me.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/