Message-ID: <Pine.LNX.4.64.0608220953090.3315@raven.themaw.net>
Date:	Tue, 22 Aug 2006 10:04:03 +0800 (WST)
From:	Ian Kent <raven@...maw.net>
To:	David Howells <dhowells@...hat.com>
cc:	Andrew Morton <akpm@...l.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: [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@...maw.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists