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

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

On Thu, Feb 18, 2016 at 07:41:19PM +0000, Adamson, Andy wrote:
> 
> > On Feb 18, 2016, at 1:32 PM, Trond Myklebust <trond.myklebust@primarydata.com> wrote:
> > 
> > On Thu, Feb 18, 2016 at 9:14 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >> 
> >> 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?).
> > 
> > The multipath policy is pluggable. If you need something more clever
> > than round robin, then feel free to play. However do note that for
> > pNFS multipathing, both the files and flexfiles specs are clear that
> > you should not mix slow and fast transports. I imagine you probably
> > want to do the same for fs_locations.
> > 
> > As for fs_locations_info, please see FSLI4BX_(READ|WRITE)(RANK|ORDER).
> 
> OK. I’m testing session trunking using new multiple hostname mount options. I’ll submit another RFC patchset.
> Then, caveat patchset response, I’ll switch from the multiple hostname mount options to fs_locations_info

You mean you want to remove support for the commandline list of
hostnames at that point?

I'd rather keep support for listing them on the commandline.  I think
the fs_locations_info is a little more complicated than I did at first
look.  (Among other things, it requires server support, and some thought
about how exactly to interpret that fs_locations_info preference
information.)

--b.