Received-SPF: pass (google.com: domain of linux-nfs+bounces-1829-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240207182912.30981-1-olga.kornievskaia@gmail.com>
 <be83ac24a9d17fc78590d4b182afd3f4e6c1e8a7.camel@hammerspace.com>
 <CAN-5tyFTx4bUvuF627E_2x9Kw2h9tccqU-7KfCtJHyFazTTLYg@mail.gmail.com>
 <CAN-5tyF2bqMy9y1rbeYbU5uakzg0AeiF7rEzH8M7S=kWyogY_w@mail.gmail.com> <10ca1cfa1243a7b039502a5cc8253a56c2572408.camel@hammerspace.com>
In-Reply-To: <10ca1cfa1243a7b039502a5cc8253a56c2572408.camel@hammerspace.com>
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Date: Wed, 7 Feb 2024 16:44:11 -0500
Message-ID: <CAN-5tyFQYVKqzansQ8E9=uKGbrhOJ_e6jzS3CeCMGPp9=aKTVQ@mail.gmail.com>
Subject: Re: [PATCH 1/1] NFSv4.1/pnfs: error gracefully on partial pnfs layout
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, 
	"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 7, 2024 at 3:42=E2=80=AFPM Trond Myklebust <trondmy@hammerspace=
.com> wrote:
>
> On Wed, 2024-02-07 at 14:58 -0500, Olga Kornievskaia wrote:
> > On Wed, Feb 7, 2024 at 2:51=E2=80=AFPM Olga Kornievskaia
> > <olga.kornievskaia@gmail.com> wrote:
> > >
> > > On Wed, Feb 7, 2024 at 2:12=E2=80=AFPM Trond Myklebust
> > > <trondmy@hammerspace.com> wrote:
> > > >
> > > > On Wed, 2024-02-07 at 13:29 -0500, Olga Kornievskaia wrote:
> > > > > From: Olga Kornievskaia <kolga@netapp.com>
> > > > >
> > > > > Currently, if the server returns a partial layout, the client
> > > > > gets
> > > > > stuck asking for a layout indefinitely. Until we add support
> > > > > for
> > > > > partial layouts, treat partial layout as layout unavailable
> > > > > error.
> > > > >
> > > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > > ---
> > > > >  fs/nfs/nfs4proc.c | 6 ++++++
> > > > >  1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > > > > index dae4c1b6cc1c..108bc7f3e8c2 100644
> > > > > --- a/fs/nfs/nfs4proc.c
> > > > > +++ b/fs/nfs/nfs4proc.c
> > > > > @@ -9790,6 +9790,12 @@ nfs4_proc_layoutget(struct
> > > > > nfs4_layoutget
> > > > > *lgp,
> > > > >       if (status !=3D 0)
> > > > >               goto out;
> > > > >
> > > > > +     /* Since client does not support partial pnfs layout,
> > > > > then
> > > > > treat
> > > > > +      * getting a partial layout as LAYOUTUNAVAILABLE error
> > > > > +      */
> > > > > +     if (lgp->args.range.length !=3D lgp->res.range.length)
> > > > > +             task->tk_status =3D -NFS4ERR_LAYOUTUNAVAILABLE;
> > > >
> > > >
> > > > I think this case is better handled by allowing the caller to set
> > > > lgp-
> > > > > args.minlength to an appropriate minimum value.
> > >
> > > I do not understand what this suggestion means. What I can think of
> > > is
> > > that the caller would set an appropriate minimum value and the code
> > > here would check that the result is at least as large?
> >
> > A follow up question on a "minimum value". It seems that since the
> > client would then need to set it to the same value as the "length"
> > (ie
> > whole file layout value), yes? So it shifts the responsibility to the
> > server, disallowing it from returning a partial layout.
>
> My expectation is that we use 'minimum length' to mean the length that
> is the smallest value that is acceptable to the client (i.e. the
> "loga_minlength" as described in RFC5661 Section 18.43). If the client
> cannot handle a layout that is smaller than a whole file layout, then
> that's the value we should set for loga_minlength. The server then gets
> to decide if it can honour the request, or should return
> NFS4ERR_LAYOUTTRYLATER.
>
> The other value is the desired length (i.e. the "loga_length" as
> described in RFC5661, Section 18.43). Currently, in the flexfiles
> client, we set that to the length of the I/O request that we're trying
> to obey. If the server can meet or exceed that value, it will still do
> so, but it doesn't need to return an error if it cannot meet that value
> provided that it can still return a layout with a length that meets the
> "loga_minlength" requirement.

I think I'm misunderstanding a partial layout and the client's ability
to support them. Is partial layout support something that generic pnfs
code does or is that something that each layout driver supposed to
support?  I was under the impression that it is or will be generic.
I'm specifically confused because in the previous email you said, the
minimal (layout) length is set to a PAGE (or I/O request size) and
that each driver is supposed to be able to handle that. That seems to
imply to me that if the server returned back a layout of 1 page
(which is a partial layout) then the layoutdriver should be OK with it
(mean handle partial layouts) (which filalyout driver does not, it
needs a whole file layout), is that correct?

>
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
>
>