On 5/30/2019 2:41 PM, Olga Kornievskaia wrote:
On Thu, May 30, 2019 at 1:41 PM Tom Talpey <tom@xxxxxxxxxx> wrote:
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?
For v3 and v4.0 in the current code base with a single connection,
when it goes down, you are out of luck. When we have multiple
connections and would like the benefit of using them but not
sacrifices replay cache correctness, it's a small price to restrict
the re-transmissions and suffer the consequence of not being able to
do an operation during network issues.
I agree that the corruption resulting from a blown cache lookup would
be bad. But I'm also saying that users will be frustrated when random
operations time out, even when new ones work. Also, I think it may
lead to application issues.
I think a common configuration will be two NICs and two network paths,
Are you talking about session trunking here?
No, not necessarily. Certianly not when doing what you propose
over NFSv3.
Why do you think two NICs would be a common configuration. I have
performance numbers that demonstrate performance improvement for a
single NIC case. I would say a single NIC with a high speed networks
(25/40G) would be a common configuration.
They're both common! And sure, it's good for a single NIC because of
RSS (receive side scaling). The multiple connections spread interrupts
over several cores. The same as would happen with multiple NICs.
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?
I think mainly because customers are still using v3 but want to
improve performance. I'd love for everybody to switch to 4.1 but
that's not happening.
Yeah, you and me both. But trying to "fix" NFSv3 with this is not
going to move the world forward, and I predict will cost many woeful
days ahead when it fails to work transparently.
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.
