From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4F83C28CC0 for ; Thu, 30 May 2019 17:41:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9988E25E9B for ; Thu, 30 May 2019 17:41:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726550AbfE3Rlb (ORCPT ); Thu, 30 May 2019 13:41:31 -0400 Received: from p3plsmtpa06-02.prod.phx3.secureserver.net ([173.201.192.103]:35986 "EHLO p3plsmtpa06-02.prod.phx3.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726307AbfE3Rla (ORCPT ); Thu, 30 May 2019 13:41:30 -0400 Received: from [192.168.0.67] ([24.218.182.144]) by :SMTPAUTH: with ESMTPSA id WP3Rh9Xstb5uOWP3RhJl1C; Thu, 30 May 2019 10:41:30 -0700 Subject: Re: [PATCH 0/9] Multiple network connections for a single NFS mount. To: Olga Kornievskaia Cc: NeilBrown , Chuck Lever , Schumaker Anna , Trond Myklebust , linux-nfs References: <155917564898.3988.6096672032831115016.stgit@noble.brown> <1df23ebc-ffe5-1a57-c40a-d5e9a45c8498@talpey.com> From: Tom Talpey Message-ID: <9b64b9d9-b7cf-c818-28e2-58b3a821d39d@talpey.com> Date: Thu, 30 May 2019 13:41:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCaGtFKeHr68geR4zP2Gn897LFsINAcADJoTJw0FZcC+QgMHJiut2ZCdIm/FW2zGJ4UH7IWsw3YriA6sJ22JIXoBpAWftcJCO+HRKpquNnrFE1lpmiQx 0GUeMBEz1OqetFFdpRy7gWpn0WW7eU6svQlycXmy0is0yMM0uRxWBxh1fC4AFjAXmznun6LgU0VK84RBqfePNeRMJ8YLSxdA4L1zr7ka051CQIG5Wy8JhqIn rtgte4lkj/t6jeZhKeQRqdlNPs3Orup97Gk01svxWwAiPGIxiaw5qulaF6LRpUY74D7OMKDoWMr/wjIvWV1dcGNZg9BZglVzwHZKQDNP4bA= Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 5/30/2019 1:20 PM, Olga Kornievskaia wrote: > On Thu, May 30, 2019 at 1:05 PM Tom Talpey wrote: >> >> On 5/29/2019 8:41 PM, NeilBrown wrote: >>> I've also re-arrange the patches a bit, merged two, and remove the >>> restriction to TCP and NFSV4.x,x>=1. Discussions seemed to suggest >>> these restrictions were not needed, I can see no need. >> >> I believe the need is for the correctness of retries. Because NFSv2, >> NFSv3 and NFSv4.0 have no exactly-once semantics of their own, server >> duplicate request caches are important (although often imperfect). >> These caches use client XID's, source ports and addresses, sometimes >> in addition to other methods, to detect retry. Existing clients are >> careful to reconnect with the same source port, to ensure this. And >> existing servers won't change. > > Retries are already bound to the same connection so there shouldn't be > an issue of a retransmission coming from a different source port. So, there's no path redundancy? If any connection is lost and can't be reestablished, the requests on that connection will time out? I think a common configuration will be two NICs and two network paths, a so-called shotgun. Admins will be quite frustrated to discover it gives no additional robustness, and perhaps even less. Why not simply restrict this to the fully-correct, fully-functional NFSv4.1+ scenario, and not try to paper over the shortcomings? Tom. > >> Multiple connections will result in multiple source ports, and possibly >> multiple source addresses, meaning retried client requests may be >> accepted as new, rather than having any chance of being recognized as >> retries. >> >> NFSv4.1+ don't have this issue, but removing the restrictions would >> seem to break the downlevel mounts. >> >> Tom. >> > >