On 5/30/2019 1:20 PM, Olga Kornievskaia wrote:
On Thu, May 30, 2019 at 1:05 PM Tom Talpey <tom@xxxxxxxxxx> wrote:
On 5/29/2019 8:41 PM, NeilBrown wrote:
I've also re-arrange the patches a bit, merged two, and remove the
restriction to TCP and NFSV4.x,x>=1. Discussions seemed to suggest
these restrictions were not needed, I can see no need.
I believe the need is for the correctness of retries. Because NFSv2,
NFSv3 and NFSv4.0 have no exactly-once semantics of their own, server
duplicate request caches are important (although often imperfect).
These caches use client XID's, source ports and addresses, sometimes
in addition to other methods, to detect retry. Existing clients are
careful to reconnect with the same source port, to ensure this. And
existing servers won't change.
Retries are already bound to the same connection so there shouldn't be
an issue of a retransmission coming from a different source port.
So, there's no path redundancy? If any connection is lost and can't
be reestablished, the requests on that connection will time out?
I think a common configuration will be two NICs and two network paths,
a so-called shotgun. Admins will be quite frustrated to discover it
gives no additional robustness, and perhaps even less.
Why not simply restrict this to the fully-correct, fully-functional
NFSv4.1+ scenario, and not try to paper over the shortcomings?
Tom.
Multiple connections will result in multiple source ports, and possibly
multiple source addresses, meaning retried client requests may be
accepted as new, rather than having any chance of being recognized as
retries.
NFSv4.1+ don't have this issue, but removing the restrictions would
seem to break the downlevel mounts.
Tom.
