> 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.
This bug has turned out to be quite puzzling, as it should have been very easy
to fix. To summarize the behavior:
(1) There are only a small number of servers in use that demand longword-sized
RPC messages, but for them the current NFS client is 100% broken.
(2) Adding pad bytes fixes the garbage args messages from such servers and
allows them to work with the Linux client.
(3) The error reports associated with adding pad bytes seem to occur only under
dynamic conditions. If the server were applying some tests to the incoming
packets and discarding them, this should show up as consistent failures. (FWIW,
I haven't seen any problems with either knfsd or unfsd.)
(4) By code inspection of the tcp sendmsg paths, putting additional bytes in an
iovec is equivalent to copying the original data to a longword-sized buffer,
which is what the 2.0.xx NFS client does.
So if the patch really is causing some kind of problem, it would appear that
either the padding calculation is wrong under some circumstances, or else the
presence of extra pad bytes or an extra iovec is triggering some other bug in
the RPC or networking layer. In the latter case, it's more important that we
track down the true problem, as otherwise it will likely reappear in a different
guise. In my experience the value of fixing a minor bug is increased if it
exposes a more serious problem.
Since we want the Linux NFS client to interoperate with all servers, I think
it's better to include the patch to address the garbage args problem, disabled
by default so that people can enable it as needed.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu