Re: [nfsv4] GETDEVICEINFO returning ENOENT

[Olga Kornievskaia <[e-mail]>]

On Wed, Jan 18, 2023 at 10:16 AM Trond Myklebust
<[e-mail]> wrote:
>
>
>
> On Jan 18, 2023, at 10:01, Olga Kornievskaia <[e-mail]> wrote:
>
> 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.
>
>
> Hmm... That behaviour appears to be specific to the files layout driver, and looks like a bug. The flex files layout driver will report the error using the layout error mechanism, and then return the layout, while the block layout marks the layout  as unavailable.
> I suggest we fix the files layout driver to drop the layout, and perhaps try to send a layout error, if the server supports that.

Yes indeed I should have said that it was just for filelayout
implementation. I will propose a fix on the mailing list then. I do
btw agree with you that it's rather questionable to make the deviceid
invalid just as it was given out in the LAYOUTGET, but it is valid as
per spec. And I thought the client should treat that the same as
LAYOUTUNAVAILABLE. But I also think that the server should then recall
the layout...

Thank you for the feedback!

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