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

[Ian Kent]

On Mon, 21 Aug 2006, David Howells wrote:

> Ian Kent <raven@xxxxxxxxxx> wrote:
> 
> > That makes it a bit hard as the /net functionality that Andrew is using is 
> > meant to mount all exports from the given server.
> 
> 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. Its basically due to the dependencies 
and the relatively simple minded way they are handled.

In version 5 they are mounted and umounted on demand.

> 
> > 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?
Not updating the mtab will be a problem for me also and possibly for 
users that expect to see mounts in it.

The "/net" functionality is a standard, expected automounter function.

> 
> 
> 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 don't quite understand the "open will cause the automount" for NFS 
version < 4. The automounter calls mount(8) when it gets a packet from the 
autofs[4] kernel module due to an access.

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.

Ian
-
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/