I suspect that there are servers out there that sanity-compare the size of
the UDP packet with the sizes inside the NFS header, and if they don't
match then the server will throw the packet away - this the "task timed
out" messages because the server will never reply to the packet even when
we re-send it.
That's also why I'm nervous about applying the patch: the current non-pad
thing seems to work for 99.5% of all servers, and I'm worried that trying
to fix the .5% that are broken will break more than it fixes.
> Can you think of any explanation for such interactions? The way the padding is
> being added only affects the RPC message length, not the payload received by the
> NFS server. FWIW, the 2.0.xx NFS client effectively pads writes by copying the
> data to a large enough buffer and leaving null bytes at the end. Since the
> 2.1.xx client is using the socket iovec facility to avoid copying the message,
> the padding needs to be added as an iovec extent, but the result seen by the
> remote end should be the same as for the 2.0.xx case.
>
> Very puzzling ..
Very puzzling if so - I haven't actually taken a look at the packets on
the wire, I just know that I saw the same behaviour. Maybe just the
padding code is subtly wrong, and maybe doesn't count all of the bytes
actually in the packet?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu