On Thu, May 30 2019, Tom Talpey 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? Path redundancy happens lower down in the stack. Presumably a bonding driver will divert flows to a working path when one path fails. NFS doesn't see paths at all. It just sees TCP connections - each with the same source and destination address. How these are associated, from time to time, with different hardware is completely transparent to NFS. > > 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? Because I cannot see any shortcomings in using it for v3 or v4.0. Also, there are situations where NFSv3 is a measurably better choice than NFSv4.1. Al least it seems to allow a quicker failover for HA. But that is really a topic for another day. NeilBrown > > 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. >>> >> >>
Attachment:
signature.asc
Description: PGP signature
