Message-ID: <33128.141.211.133.197.1073590355.squirrel@webmail.uio.no>
Date: Thu, 8 Jan 2004 20:32:35 +0100 (CET)
Subject: Re: [autofs] [RFC] Towards a Modern Autofs
From: <trond.myklebust@fys.uio.no>
To: <viro@parcelfarce.linux.theplanet.co.uk>, <linux-kernel@vger.kernel.org>
Importance: Normal
Cc: <raven@themaw.net>, <hpa@zytor.com>, <Michael.Waychison@sun.com>,
       <thockin@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2587
Lines: 58

P? to , 08/01/2004 klokka 13:31, skreiv
viro@parcelfarce.linux.theplanet.co.uk:

> Special vfsmount mounted somewhere; has no superblock associated with
> it; attempt to step on it triggers event; normal result of that event
> is to get a normal mount on top of it, at which point usual chaining
> logics will make sure that we don't see the trap until it's uncovered
> by removal of covering filesystem.  Trap (and everything mounted on
> it, etc.) can be removed by normal lazy umount.
>
> Basically, it's a single-point analog of autofs done entirely in VFS.
> The job of automounter is to maintain the traps and react to events.

What if the trap is set by the filesystem? I'm thinking about AFS
volumes and NFSv4 migration events here.

Both these need something that goes beyond the current autofs "daemon
waiting on top of a single trap" thinking.

In the NFSv4 migration case we can be walking down the filesystem patch
and enter a directory where we are basically told by the server that
"this volume has been moved" and are given a list of replicated
servername/pathname fields. Those then need to be interpreted in
userland by means of an upcall of some sort, and the new volume needs to
be mounted.

Neither autofs3 nor autofs4 can currently help us do this, because we
don't a priori have a complete list of directories on which to start a
bunch of "automount" daemons (and it wouldn't help anyway since a server
failover event etc. might cause the list to change).

Setting up our own traps, however, and then doing the upcall by means of
an exec & an "intelligent" mount program (as Mike & co. propose) OTOH,
would very much simplify matters, since that allows us to do simple
string parameter passing from the kernel to direct how the mount is to
be set up.
It still leaves the final policy decisions of which server to mount &
where in userland.

Finally, because the upcall is done in the user's own context, you avoid
the whole problem of automounter credentials that are a constant plague
to all those daemon-based implementations when working in an environment
where you have strong authentication.
If anyone wants evidence of how broken the whole daemon thing is, then see
the workarounds that had to be made in RFC-2623 to disable strong
authentication for GETATTR etc. on the NFSv2/v3 mount point.

Cheers,
  Trond


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/