Re: "Re: [PATCH RFC Version 1 0/6] Request for Comment: NFS4.1 Session Trunking"

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Feb 17, 2016 at 06:55:43PM -0500, Trond Myklebust wrote:
> On Wed, Feb 17, 2016 at 5:52 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> >
> >> On Feb 17, 2016, at 5:35 PM, Adamson, Andy <William.Adamson@netapp.com> wrote:
> >> The fs_locations would need to be requested by the client. I guess we reqest them at every mountâ€Ķ.
> >
> > Yep, and fetch them again every so often. There's no real
> > cache coherency protocol for this information. (That's
> > where a pNFS layout might be more valuable).
> 
> If your goal is to do session trunking, you only really need to check
> the fs_locations attribute on the root file system. (so
> GETROOTFH+GETATTR(fs_locations)). That's the natural place for a
> server to advertise its full set of IP addresses, and the session
> trunking protocol itself will allow you to winnow out any that might
> belong to a replica server.

I worry that round-robin could behave really badly if the client's path
to the two IP addresses have different performance characteristics.  But
a server should probably still be allowed to advertise those as replicas
(e.g.  maybe a slower interface is usable as a fallback?).

So maybe we should be careful about making this automatic.  Unless the
load-balancing is a little smarter than pure round robin.  Or unless we
can get some more fine-grained information (maybe someone could use
fs_location_info's preference information for this?).

--b.

> 
> You might want to refresh that info whenever the connection goes away
> on one or more addresses without a reboot so you can detect when NICs
> are going away.
> 
> Otherwise, polling every couple of hours or so for new NICs shouldn't
> be too burdensome...
> 
> Cheers,
>  Trond