SUMMARY: NFS/amd/network saturation problem

From: Gerald McLarnon <mclarnon_at_atm.ox.ac.uk>
Date: Mon, 01 Dec 1997 11:11:25 +0000 (GMT)

Hi

My original post was

> Two Digital UNIX boxes 4.0B saturating 10Mbps with the following
> conversation (hostnames truncated): tcpdump from linux boxes gives
>
> 12:52:14.772866 iniki.17257c85 > naomi.nfs: 128 remove [|nfs] (ttl 30, id 20696)
> 12:52:14.772866 iniki.17257c85 > naomi.nfs: 128 remove [|nfs] (ttl 30, id 20697)
> 12:52:14.772866 naomi.nfs > iniki.17257c85: reply ok 28 remove [|nfs] (ttl 30, id 11346)
> 12:52:14.772866 naomi.nfs > iniki.17257c85: reply ok 28 remove [|nfs] (ttl 30, id 11347)
>
> (repeats ad infinitum).
>
> Both running amd automounter and mounting very heavily used disks
> between each other.

Many thanks to

  Tim Janes <janes_at_signal.dera.gov.uk>
  Valeix Arnaud <arnaud.valeix_at_sncf.fr>

Tim Janes wrote:

> It turns out to be a bug in DU4.X when a remote filesystem is mounted
> nointr which is the default for amd but not the default when
> mounted from fstab.
>
> If you add the option intr to the amd map it all went away for us.
>
> ie
>
> auden/data host!=auden;type:=nfs;rhost:=auden;rfs:=/local/data;opts:=intr \
> host==auden;type:=link;fs:=/local/data
>
> I have a simple script that exercises this problem in the absence of
> amd I will try and dig it out. It has been reported to DEC but I
> gather that there has been no progress in getting a fix.

One of my amd maps had an intr and another didn't, and I can confirm
that we only observed this behaviour when the intr was missing. I have
added intr to the other map and hopefully this will have solved the problem.

Thanks again.

- Gerald
Received on Mon Dec 01 1997 - 12:30:03 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:37 NZDT