On 6 Oct 2020, at 20:18, J. Bruce Fields wrote:
On Tue, Oct 06, 2020 at 05:46:11PM -0400, Olga Kornievskaia wrote:
On Tue, Oct 6, 2020 at 3:38 PM Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
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?
What about reboot recovery? How will each mount recover its own state
(and present the same identifier it used before). Client only keeps
track of one?
Looks like nfs4_init_{non}uniform_client_string() stores it in
cl_owner_id, and I was thinking that meant cl_owner_id would be used
from then on....
But actually, I think it may run that again on recovery, yes, so I bet
changing the nfs4_unique_id parameter midway like this could cause
bugs
on recovery.
Ah, that's what I thought as well. Thanks for looking closer Olga!
I don't see why we couldn't store it for the duration of the mount, and
doing so would fix reboot recovery when the uniquifier is changed after
a
mount.
Ben
