Comment 7 for bug 480444

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.

> Now, it is odd that there is a WRITE command as part of a ftruncate()
> syscall. The WRITE carries 1024 bytest of data each time. The offset
> (place where it is supposed to be written) is always fairly small, but
> different each time.

If NFSv4 doesn't implement an ftruncate primitive, I don't think it's
strange at all to implement this on top of a write - this is probably an
extending ftruncate() call, asking the filesystem to reserve x more bytes
for the file in a block (for performance reasons) past the current end of
the file.

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.

Given the semantics of ftruncate() listed in the manpage:

   If the file previously was shorter, it is extended, and the extended
   part reads as null bytes ('\0').

and given that there doesn't appear to be an ftruncate primitive in NFSv4
that we can rely on, it would seem that we need to ask the NFS server to
write all zeroes, in the range filesize+1..length.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>