Comment 8 for bug 480444

On 24/10/10 00:32, Steve Langasek wrote:
> On Sat, Oct 23, 2010 at 09:42:27PM -0000, gpk wrote:
>> I looked at the packet storm (captured above), and it seems to be a rapid repetition of a single
>> command and a single response.
>> The command is a COMPOUND of PUTFH, WRITE, GETATTR,
>> and the server responds with NFS4ERR_OPENMODE which is
>> in response to a failure of the WRITE.
> ...
> So I guess we have two separate client bugs here: one is that the client
> fails to handle the write failure in a graceful manner (instead it tries the
> request again... "insanity is doing the same thing over and over again and
> expecting different results"); the other is that the write request is
> somehow buggy and fails to have the desired effect of extending the file.

The first is clear.
The second is not obvious. There might be legitimate reasons for the
write request failure,
such as an open with no write permissions. Or, maybe file locking.
It suggests a bug somewhere, but the bug might not be in the write code
itself.
Could be something that happens at the very beginning of the storm.
Possibly, it might even be in bzr.

There's something else a slightly weird, though. In the other packet
storm (mine), there is
a RENEW call. RFC3010 says there is an implicit lease renewal caused
by LOCK and WRITE
calls, so why is the RENEW call needed at all?

I get COMPOUND call<EMPTY tag> PUTFH; LOCK
... PUTFH; WRITE; GETATTR
... RENEW
... PUTFH; LOCK
          (tries to set a WRITE_LT lock)
... PUTF; WRITE; GETATTR
          The write is always 543 bytes;
           The getattr asks for FATTR4_CHANGE and FATTR4_SIZE
                             and FATTR4_TIME_METADATA and FATTR4_TIME_MODIFY
... RENEW
... PUTFH; LOCK
... PUTFH; WRITE; GETATTR
... RENEW
et cetera
The "renew" calls succeed with NFS4_OK
PUTFH; LOCK succeeds with NFS4_OK (twice).
PUTFH; WRITE; GETATTR fails on the WRITE with NFS4ERR_OPENMODE