On Tue, 2017-08-15 at 17:46 -0700, Bennett Amodio wrote:
> After seeing Trond’s patches for NFS multipathing on NFSv4.1, we
> decided to try using the same concept for NFSv3/4. The primary issue
> we identified was XID collision in the duplicate request cache
> (replay
> cache) for NFSv3/4. In NFSv3/4, entries are hashed based on XID
> instead of the slot ID and sequence ID that NFSv4.1 uses. Since the
> XIDs are generated by the RPC transports, and Trond’s patches create
> multiple transports for multipathing, different transports can end up
> using an overlapping set of XIDs.
Why is that a problem? You should end up with connections that show
different combinations of source IP+port and/or destination IP+port. It
should be trivial to distinguish between XIDs.
Quite frankly, I do not want to start carving up the XID space, since a
32-bit number is really not that big in these days of 100GigE networks.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
