To: amd-workers@acl.lanl.gov
Subject: 2 amd problems
X-Face: %2'i#(dROd-(2'`-!U)}q'%u@:^gnvj42}w_%pfh'2:An:m%i6{-2[':9~|7xX|:L`SHO'p
	 ]-UMALX=kqKk8|HKk4\Pmw5DcsyJ?[ZAAjN=?>!.1K%}GUW"d8!@E&|NA[EyQ~TEtIW]2QYs:NJN{L
	 yVwN(xW]~k|%U9apQK7M'ffVwjtmj&Ep_mO#}?k?yxDp!p:nEO\mS*KK0S}~a]H>n"WGvr;eO%uw[`
	 |Dt'A/8}mWhfT
Date: Mon, 23 Mar 92 16:22:21 PST
From: Andreas Stolcke <stolcke>


Hi,

I'm new to this list, which I figured it would the right forum for getting
feedback on two problems we have been having with amd.  I'm referring to
amd 5.2.1.14 of 1991/09/15 20:15:54 5.3alpha #13: Sat Feb  1 14:02:49 PST 1992
Built by stolcke@icsib30 for a sun4 running sos4,
but the first problem is generic to all platforms.
I have looked at 5.3beta recently, but the relevant source seems to be
unchanged.

Problem #1:

Amd doesn't use the UMOUNT rpc to inform remote mount daemons that something
is no longer mounted.  That way, over time, basically all exported 
filesystems on our network accumulate in /etc/rmtab on most machines,
and when you do a shutdown(8) notifications are sent to every single machine.

I realize that the mount protocol is problematic with respect to umounts
(e.g., even with regular mount/umount I can easily get the remote mountd
out of sync with what it actually mounted).  But an approximate solution,
i.e., one that usually works, would be better that no solution at all in
this case.

The solution we are currently using is to use the code in amd/nfs_ops.c
that's #ifdef'ed with INFORM_MOUNTD and a small addition to amd/host_ops.c
that issues a MOUNTPROC_UMNTALL rpc.  This seems to work nicely for us
and gets rid of the problem described above.

Problem #2:

On diskless Suns (Sunos4.1.1) that have their /etc/mtab on an NFS filesystem
the locking scheme in config/mtab_file.c doesn't seem to work.  The
bottom line is that after concurrent umount attempts by backgrounded
amd processes old entries remain in /etc/mtab.  I'm pretty sure this is
a bug in Sun's NFS locking support in the kernel, but even with all the latest
OS patches installed the problem persists and is a real nuisance.

Specifically what seems to be confusing the system is the renaming of the
old mtab file.  I rewrote config/mtab_file.c to do the update of /etc/mtab
in place, ie., without creating a new file and then moving it in place.
Theoretically there is a higher risk involved in that the mtab may be
completely lost if something goes wrong,  but this never seems to happen
in practice and it got rid of the locking trouble and left-over mtab entries.

So, although we have workarounds for both these problems I'd be interested
in knowing if others have encountered similar problems and how (if at all)
they were solved).

BTW, other than that I think amd is a great piece of software.

--Andreas