Re: [nfsv4] GETDEVICEINFO returning ENOENT

[Olga Kornievskaia <[e-mail]>]

On Tue, Jan 17, 2023 at 5:54 PM Trond Myklebust <[e-mail]> wrote:
>
>
>
> > On Jan 17, 2023, at 17:37, Olga Kornievskaia <[e-mail]> wrote:
> >
> > Hi folks,
> >
> > Is there anything in the spec or elsewhere to let the client decide if
> > NFS4ERR_NOENT is a temporary or a permanent error for GETDEVICEINFO
> > operation?
> >
> > Right now a linux client treats it as a temporary error and triggers a
> > GETDEVICEINFO call before every IO call (until it gets a positive
> > answer). The client then proceeds to do the operations against the
> > MDS. But shouldn't ENOENT be equivalent to LAYOUTUNAVAILABLE error
> > which the client treats like a bit more permanent error and doesn't
> > ask for a layout on every IO after failing. It would seem logical that
> > if ENOENT means the server doesn't know this deviceid which was gotten
> > from a layout then should the client throw away the layout and ask
> > again for the layout?
> >
> > Thank you.
>
> Why would a server deliberately hand out a layout containing a deviceid that it cannot translate? That makes no sense, and can only be considered to be buggy server behaviour.
>
> The current Linux client code assumes that if GETDEVICEINFO returns NFS4ERR_NOENT, then the deviceid, and hence the layout have been revoked by the server, and that retrying the layoutget will yield a new, valid layout with a valid deviceid.

As I mentioned, the current linux code doesn't treat the NFS4ERR_NOENT
as what you describe. It re-tries (GETDEVICEINFO) on every single IO
call. I was looking for clarification to fix the linux client to treat
NFS4ERR_NOENT as NFS4ERR_LAYOUTUNAVAILABLE.

>
> _________________________________
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [e-mail]
>