On Mon, 21 Aug 2006, David Howells wrote:
OK. I think I get it now.
Thanks for your patience.
> Ian Kent <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
