On Tue, 2021-01-19 at 17:22 -0500, bfields@xxxxxxxxxxxx wrote: > On Wed, Oct 07, 2020 at 04:50:26PM +0000, Trond Myklebust wrote: > > As far as I can tell, this thread started with a complaint that > > performance suffers when we don't allow setups that hack the client > > by > > pretending that a multi-homed server is actually multiple different > > servers. > > > > AFAICS Tom Talpey's question is the relevant one. Why is there a > > performance regression being seen by these setups when they share > > the > > same connection? Is it really the connection, or is it the fact > > that > > they all share the same fixed-slot session? > > > > I did see Igor's claim that there is a QoS issue (which afaics > > would > > also affect NFSv3), but why do I care about QoS as a per-mountpoint > > feature? > > Sorry for being slow to get back to this. > > Some more details: > > Say an NFS server exports /data1 and /data2. > > A client mounts both. Process 'large' starts creating 10G+ files in > /data1, queuing up a lot of nfs WRITE rpc_tasks. > > Process 'small' creates a lot of small files in /data2, which > requires a > lot of synchronous rpc_tasks, each of which wait in line with the > large > WRITE tasks. > > The 'small' process makes painfully slow progress. > > The customer previously made things work for them by mounting two > different server IP addresses, so the "small" and "large" processes > effectively end up with their own queues. > > Frank Sorenson has a test showing the difference; see > > https://bugzilla.redhat.com/show_bug.cgi?id=1703850#c42 > https://bugzilla.redhat.com/show_bug.cgi?id=1703850#c43 > > In that test, the "small" process creates files at a rate thousands > of > times slower when the "large" process is also running. > > Any suggestions? > I don't see how this answers my questions above? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
