> the autofs in Solaris mounts remote filesystems directly to the logical
> path [...].
> NetBSD's amd(8) use[s] an indirect mount like this:
> tron@lyssa:~>ls -l /home/tron
> lrwxrwxrwx  1 root  wheel  28 Apr  8 17:08 /home/tron -> /amd/colwyn/export/home/tron

> I wonder what the technical reasons for this behavior are. Couldn't
> it just mount the remote filesystem over its pseudo filesystem?

In principle, it could.  I don't know why it doesn't; I didn't design
it, after all.  I would guess that this is done so as to make it
possible for amd to notice many of the references to the filesystem
(because the symlink is provided by amd).

With the Solaris scheme, unless they have kernel hooks (which they may
well have, for all I know), amd can't tell whether a filesystem is
still busy without trying to unmount it.  If the unmount succeeds and
the filesystem is still busy in a long-term sense (but just happened to
be non-busy at the moment the unmount happened), a remount will follow
immediately.  This will not bother most programs, but code which
expects <dev,ino> pairs to remain constant can be broken.  The amd
scheme allows amd to notice some accesses to the filesystem without
having to unmount and remount it, because amd is responsible for
supplying the symlink.  This does not eliminate the danger of
unmounting an idled-out filesystem, remounting it later, and breaking a
program that expects <dev,ino> pairs to remain fixed, but it does
reduce the risk.

It also allows amd to failover to an alternative filesystem in case the
primary goes dead, even if the primary mount can't be unmounted for any
reason (for example, because there are additional mounts underneath
it), by simply changing where the symlink points.

Of course, I could also be completely wrong.  It wouldn't be the first
time and won't be the last....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B