On 10/6/2020 11:22 AM, Bruce Fields wrote:
On Tue, Oct 06, 2020 at 11:20:41AM -0400, Chuck Lever wrote:
On Oct 6, 2020, at 11:13 AM, bfields@xxxxxxxxxxxx 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 thought this was what the nconnect mount option was for.
I've suggested that. It doesn't isolate the two mounts from each other
in the same way, but I can imagine it might make it less likely that a
user on one mount will block a user on another? I don't know, it might
depend on the details of their workload and a certain amount of luck.
Wouldn't it be better to fully understand the reason for the
performance difference, before changing the mount API? If it's
a guess, it'll come back to haunt the code for years.
For example, maybe it's lock contention in the xprt transport code,
or in the socket stack.
Just askin'.
Tom.
