On Thu, Oct 08, 1998 at 09:37:43PM +1000, Robert Elz wrote:

>   | This may be related to PR bin/6037.
> 
> I doubt it (or rather, if the two are related, it is more likely that the
> amd problem is a symptom of a basic kernel NFS problem.)

"Me too." I've never used amd, and I still see broken behaviour.

As an example of what goes wrong, I can do something like:

mount -t nfs styx:/seagate /seagate

and the filesystem will be mounted properly. I can cd into it and look
around with ls, as long as there isn't a lot of data to be transferred.
However, if there's a lot, the ls process will zombify, and I won't be
able to kill it with anything short of a reboot.

Also, cp'ing stuff produces the same behaviour. A file will appear on the
target system with the correct name, ownership, and permissions, but it
will be zero bytes long, and the cp will be zombified. (Not really a word,
that, but I like it.)

FWIW, I'm doing these mounts by hand, not using amd or even fstab entries.

I never see any ill effects in aggregate with this, FWIW. And, again, Linux
seems to do the right thing, and 1.3.2 on both ends did the right thing, so
it's not anything to do with the hardware, which has been working without
error for aeons. :)

Later...

PS: I'm using a kernel build four days ago, and a userland built three days
ago, today being 1998.10.08.

-- 
Mason Loring Bliss..mason@acheron.middleboro.ma.us..acheron.dyn.ml.org/mason
"In the drowsy dark cave of the mind dreams build their nest with fragments
  dropped from day's caravan."--Rabindranath Tagore..awake ? sleep : dream;