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