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;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: unsharing tcp connections from different NFS mounts
Date:   Tue, 06 Oct 2020 15:36:07 -0400
Message-ID: <95542179-0C20-4A1F-A835-77E73AD70DB8@redhat.com>
In-Reply-To: <20201006151335.GB28306@fieldses.org>
References: <20201006151335.GB28306@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 6 Oct 2020, at 11:13, J. Bruce Fields wrote:

> 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?

I suppose you could just toggle the nfs4_unique_id parameter.  This 
seems to
work:

flock /sys/module/nfs/parameters/nfs4_unique_id bash -c "OLD_ID=\$(cat 
/sys/module/nfs/parameters/nfs4_unique_id); echo imalittleteapot > 
/sys/module/nfs/parameters/nfs4_unique_id; mount -ov4,sec=sys 
10.0.1.200:/exports /mnt/fedora2; echo \$OLD_ID > 
/sys/module/nfs/parameters/nfs4_unique_id"

I'm trying to think of a reason why this is a bad idea, and not coming 
up
with any.  Can we support users that have already found this solution?

Ben