> > On Mar 23, 2021, at 2:01 PM, Nagendra Tomar > <Nagendra.Tomar@xxxxxxxxxxxxx> wrote: > > > >> The other alternative is to make the load balancer sniff the FH from each > >> NFS request and direct it to a consistent NFSv3 DS. I still prefer that > >> over adding a very special-case mount option to the Linux client. Again, > >> you'd be deploying a code change in one place, under your control, instead > >> of on 100's of clients. > > > > That is one option but that makes LB application aware and potentially less > > performant. Appreciate your suggestion, though! > > You might get part of the way there by having the LB direct > traffic from a particular client to a particular backend NFS > server. The client and its applications are bound to have a > narrow file working set. Yes, with the limitation that one client will only be served by one cluster node. This is not as good as distributing different files to different nodes, which would get the highest aggregate throughput/IOps possible. > > > > I was hoping that such a client side change could be useful to possibly more > > users with similar setups, after all file->connection affinity doesn't sound too > > arcane and one can think of benefits of one node processing one file. No? > > That's where I'm getting hung up (outside the personal preference > that we not introduce yes another mount option). While I understand > what's going on now (thanks!) I'm not sure this is a common usage > scenario for NFSv3. Other opinions welcome here! > > Nor does it seem like one that we want to encourage over solutions > like pNFS. Generally the Linux community has taken the position > that server bugs should be addressed on the server, and this seems > like a problem that is introduced by your middlebox and server > combination. I would like to look at it not as a problem created by our server setup, but rather as "one more scenario" which the client can much easily and generically handle and hence the patch. > The client is working properly and is complying with spec. The nconnect roundrobin distribution is just one way of utilizing multiple connections, which happens to be limiting for this specific usecase. My patch proposes another way of distributing RPCs over the connections, which is more suitable for this usecase and maybe others. No violation of any spec 😊 > > If the server cluster prefers particular requests to go to particular > targets, a layout is the way to go, IMHO. > > (I'm not speaking for the NFS client maintainers, just offering an > opinion and hoping my comments clarify the scenario for others on > the list paying attention to this thread). Appreciate your comments, thanks! It's always great to hear from other well-informed users. > > -- > Chuck Lever > >
