> I'd like to have others test this out for a bit: I actually tried the
> first "pad to longword" patch you sent out, and it resulted in some
> strange NFS behaviour for me (notably it made my mail-connections lock up:
> probably because my mail-client is one of the few programs that does a lot
> of unaligned writing due to writing out single messages with a fsync() in
> between..)
Hi Linus,
I have one other report of strange interactions with padding to longword, which
is that it seemed be associated with getting "RPC: task timed out" messages
during a nightly build at one tester's site. I can't imagine how adding 1-3
bytes to the end of a message could have any side effects, but that's why that
part of the patch isn't enabled by default.
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 ..
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu