Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp365683pxu; Tue, 6 Oct 2020 08:14:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCJ2GGIMZIYZPwjU3QNkDKdQBzKT88JZWnpizWRZdNsGKNRq4zITnB/10bo7WvDWaVOxAn X-Received: by 2002:a17:906:ad5:: with SMTP id z21mr5498406ejf.461.1601997278363; Tue, 06 Oct 2020 08:14:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601997278; cv=none; d=google.com; s=arc-20160816; b=pucSqpXpo7/KneDMuAQtad3bLluf4za58hvCtFJNAfnd4mlX/hGbW7c9mCF9gYY+VI uF0rJnnQRywKbostbHtHbsSmY0UmqLFR3L+8n/CoClab8DcqCHO0Mt9xBvUXp0d71nn/ Z/ZhC4muJ9NfA52IRWPqJlTfyChV+4dspgutZ3ddXkYYRhay0ogYnXDo2+KnXnLlDmJG 5mfm+HGl/Q1A+Ti39DgPt611i+qT+BVOnM7DtKTlkSX759eeVJDenLN4uAmgadBrdqE6 semYZabwH+qsdQAJYCFt0lB7K2xUEDRLrIFjKIKm58mbkpL43Yf2G7mb8lNZx8/hXN3a KL4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:from:user-agent:content-disposition:mime-version :message-id:subject:to:date:dkim-signature:dkim-filter; bh=8BPexV5KqD7xKJ7XgsEB4+OnSEoH97uVeJy4DskuRgo=; b=HAZNyZK8poUz+sGB0J1O6LyMilOB5DFDJfdJhqoI4GB2aM4HI7zK3/OeCEl+fvBkBX 3Co6jlqfA9FOV5YCvcGOAUcVrKSqCc8dNV1uyGLKVO0fk9YFt2qSIaLUFvU0/zb9aEQA HnXDKjf1XlHdSLQj7P5FeEzEmf7vAMUZdvqn7zDdJ6eouHr0Ja09k+usOxQy1Xsz80+d z5mOT1ZGXe1gZZ2P4x5cHAMlRAXQGN2nIyxj7RNyzjLTaDDYAWnnVYqRrE9NHpOPLOgu EGeqbhBqYpH+E8oYsw0oxSkxt5d5VwLNplQvdNoRlTW3Fadsu7A+n6kYdtpqbldrBoQI nt9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=sUWsdXHa; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si2688510eds.17.2020.10.06.08.13.39; Tue, 06 Oct 2020 08:14:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=sUWsdXHa; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725943AbgJFPNi (ORCPT + 99 others); Tue, 6 Oct 2020 11:13:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbgJFPNh (ORCPT ); Tue, 6 Oct 2020 11:13:37 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70330C061755 for ; Tue, 6 Oct 2020 08:13:37 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id D1A596EEE; Tue, 6 Oct 2020 11:13:35 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org D1A596EEE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1601997215; bh=8BPexV5KqD7xKJ7XgsEB4+OnSEoH97uVeJy4DskuRgo=; h=Date:To:Subject:From:From; b=sUWsdXHadEPLwPA0MLnFX0lr3vNkJsN8kp6DW5D3qZkg38EwYz8yZdl3/nzNxLxFB MRtp4lJGwQ4XfE10Yzy3u00huvsB2oLnbbAllYOvcfxKcVEZ1mChkcc2HoCAGD0TIc l2XlgfY8vMYzrhpyTXxEqpLhfhJxeaZl/SEzMEwU= Date: Tue, 6 Oct 2020 11:13:35 -0400 To: linux-nfs@vger.kernel.org Subject: unsharing tcp connections from different NFS mounts Message-ID: <20201006151335.GB28306@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org NFSv4.1+ differs from earlier versions in that it always performs trunking discovery that results in mounts to the same server sharing a TCP connection. It turns out this results in performance regressions for some users; apparently the workload on one mount interferes with performance of another mount, and they were previously able to work around the problem by using different server IP addresses for the different mounts. Am I overlooking some hack that would reenable the previous behavior? Or would people be averse to an "-o noshareconn" option? --b.