Subject: Re: [nfsv4] [PATCH 1/1] NFSD fix handling of NFSv4.2 SEEK for data within the last hole

From: [email-masked] (J. Bruce Fields)
Date: Fri, 2 Apr 2021 17:01:57 -0400

Adding [email-masked]:

On Thu, Apr 01, 2021 at 09:32:05PM +0000, Rick Macklem wrote:
> I discussed this on [email-masked] some time ago.
> The problem with "fixing" the server is that it breaks
> the unpatched Linux client.
> 
> If the client is careful, it can work correctly for both a Linux
> and RFC5661 conformant server. That's what the FreeBSD
> client tries to do.
> --> I'd suggest that be your main goal.
> 
> The FreeBSD server ships "Linux compatible", but there is
> a switch to make it RFC5661 compatible.
> --> I wouldn't make it default the RFC compatible for
>       quite a while after the client that handles RFC compatible
>       ships.
> 
> I tried to convince folks to "errata" the RFC to Linux
> compatible (since Linux was the only shipping 4.2 at
> the time, but they did not consider it an "errata").

Previous discussion here:

	https://mailarchive.ietf.org/arch/msg/nfsv4/bPLFnywt1wZ4kolMkzeSYca0qIM/

There's no rejection on that thread, was it elsewhere?

--b.

---

From: David Noveck <[email-masked]>
Date: Fri, 2 Apr 2021 22:58:15 -0400

> > the unpatched Linux client.

Yes.  As I understand it, even though  RFC7862 defines the eof flag and is
explicit about it's use, the Linux client never looks at it.

> > and RFC5661 conformant server.

I think you mean RFC7862 conformant.

It can look at the eof flag and accept either it or ENXIO as indicating a
seek beyond eof.

That'sss what the FreeBSD
> > --> I'd suggest that be your main goal.

it doesn't make sense to be deliberately incompatible with either the
existing Linux server or the RFC.

> > I tried to convince folks to "errata"

theee RFC to Linux
> > the time, but they did not consider it an "errata").

Normally if one rhinks there is an change to be made, one files an errata
report, but none was ever filed.

> There's no rejection on that thread, was it elsewhere?

No, since there was no errata report written to be accepted or rejected,
discussion went on for a time and ended without result.

However, if one had been made, it would have been rejected.   It is not the
function of the errata mechanism to make substantive protocol changes like
this, even if the wg thinks the original consensus decision was wrong.  To
do that you need a standards-track document updating the original one and
addressimg compatibility issues. Nobody was up for that at the time or
seems to be now.

>
> --b.
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 5 Apr 2021 10:06:32 -0400

> addressimg compatibility issues. Nobody was up for that at the time or

Do we have any sort of informal todo list for a 7862bis?

--b.

---

From: David Noveck <[email-masked]>
Date: Wed, 7 Apr 2021 06:46:08 -0400

No, we don't.  We could maintain one as a wg informational document.  "We
need someone to volunteer to be the editor", he said pointedly. :-)

---

From: "Frank Filz" <[email-masked]>
Date: Fri, 9 Apr 2021 13:24:55 -0700

> > The problem with "fixing" the server is that it breaks the unpatched
> > Linux client.
> >
> > If the client is careful, it can work correctly for both a Linux and
> > RFC5661 conformant server. That's what the FreeBSD client tries to do.
> > The FreeBSD server ships "Linux compatible", but there is a switch to
> > make it RFC5661 compatible.
> > I tried to convince folks to "errata" the RFC to Linux compatible
> > (since Linux was the only shipping 4.2 at the time, but they did not
> > consider it an "errata").
> 

Yea, it would be nice to resolve this. I remember having to tweak Ganesha's
implementation to not break the Linux client.

I'm still not sure I got it right...

Frank