On Wed, Sep 19, 2018 at 11:33 PM, William Allen Simpson <william.allen.simpson@gmail.com> wrote:

On 9/18/18 12:58 PM, Kropelin, Adam wrote:

NFSv4.0, nolock:

10.2.145.170:/test on /home/ec2-user/mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.98.13,local_lock=none,addr=10.2.145.170)

Try V4.1. V4.0 is only best effort, but not performance. V3 we try
not to break entirely.

What makes you think that his problem is going to go away with NSFv4.1? I am pretty sure that the same issues exists in all versions.

Also, you are overriding the read and write sizes. It shouldn't be
terribly surprising that there's not enough buffer space. We're not
allocating that much memory.

That is the default read/write size with GPFS FSAL. Smaller values generally perform poorer!

To be fair, the system was never fully async.

Especially in Ganesha V2.5. A lot of the async I-O code didn't go in
until V2.6. I merely wrote it against V2.3. It took a long time to
be integrated.

Note I mentioned that a predecessor had decided upon writev(). All
I've done is work around it. Repeatedly. Don't blame the messenger.
(That old code wouldn't even pass pynfs. So you're welcome.)

Let not blame anyone here as that is NOT going to solve anything.

Piggy indeed. [...] A server needs to cope with clients doing things that aren't always optimal.

Nope. The server needs to STARVE clients that aren't optimal. That's
also the philosophy in the kernel TCP and net stack. And pretty much
every router and switch in the network path.

Correct, but I don't see any bad client here. Unfortunatley, we are starving good clients here as we were waiting in writev() with slow clients (I don't want to call them bad clients though).

Regards, Malahal.

__
Devel mailing list -- devel@lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org