Received-SPF: pass (google.com: domain of linux-nfs+bounces-1081-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CAAvCNcDtTNDRvUVjUy4BE7eBCgmkb6hfkq3P0jaGDC=OXg0=6g@mail.gmail.com>
 <CAKAoaQmmEv+HRjmBMrSMGZn9RQr8C=2W4yeX4vNnohXFJPCV5A@mail.gmail.com>
 <65a29ca8.6b0a0220.ad415.d6d8.GMR@mx.google.com> <CAKAoaQkZ+b7NfrVi=gu1vCJBvv10=k85bG_kZV9G3jE45OOquw@mail.gmail.com>
 <0cd8fbfc707f86784dc7d88653b05cd355f89aad.camel@kernel.org> <24ACA376-5239-4941-BE53-70BF5E5E4683@oracle.com>
In-Reply-To: <24ACA376-5239-4941-BE53-70BF5E5E4683@oracle.com>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Sun, 14 Jan 2024 18:50:31 +0100
Message-ID: <CALXu0UeyKvDNx7uM5RDynT=V8YXa27AZ1YNH_A9bBCvBsjrXxw@mail.gmail.com>
Subject: Re: kernel.org list issues... / was: Fwd: Turn NFSD_MAX_* into
 tuneables ? / was: Re: Increasing NFSD_MAX_OPS_PER_COMPOUND to 96
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>, Roland Mainz <roland.mainz@nrubsig.org>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 13 Jan 2024 at 17:11, Chuck Lever III <chuck.lever@oracle.com> wrot=
e:
>
>
>
> > On Jan 13, 2024, at 10:09=E2=80=AFAM, Jeff Layton <jlayton@kernel.org> =
wrote:
> >
> > On Sat, 2024-01-13 at 15:47 +0100, Roland Mainz wrote:
> >>
> >> On Sat, Jan 13, 2024 at 1:19=E2=80=AFAM Dan Shelton <dan.f.shelton@gma=
il.com> wrote:
> > Is there a problem with that (assuming NFSv4.1 session limits are honor=
ed) ?
>
> Yes: very clearly the client will hit a rather artificial
> path length limit. And the limit isn't based on the character
> length of the path: the limit is hit much sooner with a path
> that is constructed from a series of very short component
> names, for instance.
>
> Good client implementations keep the number of operations per
> COMPOUND limited to a small number, and break up operations
> like path walks to ensure that the protocol and server
> implementation do not impose any kind of application-visible
> constraint.

This is not "good client implementation", this is bad design to force
single operations into smaller pieces.

This has drastic implications, and all are BAD:
- increased latency, by adding more round trips to complete a single
vfs operation. Right now the NFSv4 Linux server implementation already
has enough issues with bad latency
- increased volume of network traffic
- decreased throughput
- worker threads have less to do per compound, but the number of
compounds goes up. But neither are there more server threads, and the
per compound overhead is static, and just multiples with the
additional requests

This is basically what ruined X11 in the long run. The protocol split
everything into little requests, but over 20 years the networks did
not scale with the increment in CPU power, making X11 less and less
capable over the network. No one added more complex and powerful X11
requests, dooming the X11 performance over network.

So the Linux NFSv4 implementation is now doing the same, but at least
the protocol has knobs to scale it better.

Ced
--=20
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur