Return-Path: Received: from fieldses.org ([173.255.197.46]:36988 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425429AbcBROOs (ORCPT ); Thu, 18 Feb 2016 09:14:48 -0500 Date: Thu, 18 Feb 2016 09:14:47 -0500 From: "J. Bruce Fields" To: Trond Myklebust Cc: Chuck Lever , "Adamson, Andy" , Martin Houry , Linux NFS Mailing List Subject: Re: "Re: [PATCH RFC Version 1 0/6] Request for Comment: NFS4.1 Session Trunking" Message-ID: <20160218141447.GB4256@fieldses.org> References: <20160217205929.GF10401@fieldses.org> <3B48A59F-638A-45C9-B2E4-2D65C00DE639@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Feb 17, 2016 at 06:55:43PM -0500, Trond Myklebust wrote: > On Wed, Feb 17, 2016 at 5:52 PM, Chuck Lever wrote: > > > >> On Feb 17, 2016, at 5:35 PM, Adamson, Andy 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