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@xxxxxxxxxxxxxxx> wrote: > > > > On Thu, Feb 18, 2016 at 9:14 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxx> wrote: > >>>> > >>>>> On Feb 17, 2016, at 5:35 PM, Adamson, Andy <William.Adamson@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
