[272] in Athena Bugs

home help back first fref pref prev next nref lref last post

No subject found in mail header

daemon@ATHENA.MIT.EDU (don@ATHENA.MIT.EDU)
Thu Apr 28 21:26:57 1988

From: <don@ATHENA.MIT.EDU>
Date: Thu, 28 Apr 88 21:23:19 EDT
To: bugs@ATHENA.MIT.EDU
Cc: geer@ATHENA.MIT.EDU, gfi@ATHENA.MIT.EDU, saltzer@ATHENA.MIT.EDU,
i built a kernel for drgonzo, with two zero-block bug-fixes from SUN:

one is a new version of rpc/clnt_kudp.c, which bill s. tried installing
on a vax (priam?) about 2-3 weeks ago. this version, according to its source,
brad taylor at sun (calif), is the main difference between 3.2 nfs & 3.5 nfs.
eyeballing the code, it seems to address timing & interruptibility problems,
on the client-side.

the other fix, which win suggested to me today after he talked to someone @
sun, was a two-line change to nfs/nfs_vnodeops.c . it was intended to
to fill much of the zero-block-related gap between our 3.0 nfs and the 3.2
release. this fix, according to win's contact, prevents the premature removal
of client-requests from the client's queue.

the two fixes together did not suffice to fix the bug; i tested drgonzo as
a client, with its new kernel, and used koala-at & tartaros for extra
nfs-pressure. the server was minos. each client ran two hammers.

taylor told me that their 4.0 release of nfs should solve this problem even
more assiduously than 3.5, but he also said that the public-domain version
isn't ready yet. he emphasized that 3.5 differs only slightly from 3.2,
and claimed that what he sent bill sommerfeld is the most relevant difference
between 3.2 & 3.5. in sum, he thinks we could get away with porting 3.2
as our first step, and applying the rest of 3.5's increments as needed.
since 3.4/3.5 will probably take a while to arrive at our door, the 3.2 port
seems more attractive now, after all.
						-don

home help back first fref pref prev next nref lref last post