Message-ID: <15387.1156173472@warthog.cambridge.redhat.com>
Date:	Mon, 21 Aug 2006 16:17:52 +0100
From:	David Howells <dhowells@...hat.com>
To:	Ian Kent <raven@...maw.net>
Cc:	David Howells <dhowells@...hat.com>, 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] 

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.

For example, on my test machine:

	[root@...romeda ~]# /root/mount warthog:/ /warthog -o fsc
	[root@...romeda ~]# ls /warthog/warthog
	[root@...romeda ~]# cat /proc/mounts 
	...
	warthog:/ /warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
	warthog:/warthog /warthog/warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
	[root@...romeda ~]# umount /warthog/
	[root@...romeda ~]# 

The "ls" command caused the client to mount warthog:/warthog off of the server
onto /warthog/warthog automatically.  I was then able to just unmount
/warthog, which took away /warthog/warthog also without me having to do
anything special.

> In version 5 they are mounted and umounted on demand.

This should now be left to the NFS client.

The NFS client now views each set of files with the same FSID as a separate
collection of files, and accords each set its own superblock.  The superblocks
thus created are automounted by the follow_link() op on the directory that's
at the point of FSID-change.

Note!  This works for NFS2, NFS3 and NFS4.  NFS4 has an extra facility by
which mounts can cross servers, but that uses more or less the same mechanism.

> > > In v4 that are mounted and umounted as a unit to deal with the nesting.
> > 
> > Why does the automounter daemon have to do the mounting of submounts?
> > What's wrong with having the kernel do it?  The one problem with having
> > the kernel do it that I can see, is that the kernel doesn't update
> > /etc/mtab.
> 
> v2 and v3 won't do the expire, will they?

Yes.  Automounting and auto-expiration both.

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

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

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

> I expect that I won't have to do much at all for xdev mounts except to be 
> able to recoginize them and their owners so I can leave them alone. The 
> expire function might be a bit interesting.

They're self-expiring.  And, as I mentioned above, you only need to unmount
the root to dispose of the entire tree.

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