Return-Path: Received: from mail-ob0-f176.google.com ([209.85.214.176]:35086 "EHLO mail-ob0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965013AbcBQXzo convert rfc822-to-8bit (ORCPT ); Wed, 17 Feb 2016 18:55:44 -0500 Received: by mail-ob0-f176.google.com with SMTP id xk3so41118533obc.2 for ; Wed, 17 Feb 2016 15:55:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20160217205929.GF10401@fieldses.org> <3B48A59F-638A-45C9-B2E4-2D65C00DE639@netapp.com> Date: Wed, 17 Feb 2016 18:55:43 -0500 Message-ID: Subject: Re: "Re: [PATCH RFC Version 1 0/6] Request for Comment: NFS4.1 Session Trunking" From: Trond Myklebust To: Chuck Lever Cc: "Adamson, Andy" , "J. Bruce Fields" , Martin Houry , Linux NFS Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: 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. 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