[166] in Athena Bugs
No subject found in mail header
daemon@ATHENA.MIT.EDU (don@ATHENA.MIT.EDU)
Thu Apr 7 21:35:17 1988
From: <don@ATHENA.MIT.EDU>
Date: Thu, 7 Apr 88 21:34:09 EDT
To: bugs@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU, gfi@ATHENA.MIT.EDU,
more on the nfs-zero-block bug:
* two hammers suffice to demonstrate the bug when priam is the server;
since bill disenabled his asynchronous-writes on priam on friday,
this seems to exculpate bill's code, but it means his quick-fix
doesn't fix the bug completely.
* this also means that 5.5t's client's stimulation of the bug
does NOT prove that the bug must be in the checksumming-server.
* it was suggested to me that if the bug were in the client,
it would probably lie in the biods' management of their common
queue & buffers; ultrix has had a bug of this sort.
* the point is that biod's are not essential to an nfs client;
without biod's, each nfs-write blocks the client.
with biod's, the client's nfs-writes are queued,
and, by turns, each biod services one queued write-request.
* the scenario is that a biod may trash queued buffer-contents.
thus, a subsequently-executing biod might find zeroes in its buffer,
and faithfully ship them to the server.
so, the test of this hypothesis was to run hammers without biod's,
along with hammers having biod's ( extra load on the server).
biod-less clients still triggered the bug.
since biod-less clients don't queue nfs-requests,
queue-management isn't involved on the client side.
this doesn't necessarily localize the bug to server-side, but we've
one less hypothesis, and the server could still be at fault.
-don