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). -- 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
