Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
MIME-Version: 1.0
References: <CANH4o6PU1p6NzS3X6ohGFPjzxKXr3gXn70s-VV+HSzAAPbWyvQ@mail.gmail.com>
 <08A8C65F-5755-41DC-B29A-DE168B23C968@redhat.com>
In-Reply-To: <08A8C65F-5755-41DC-B29A-DE168B23C968@redhat.com>
From:   Martin Wege <martin.l.wege@gmail.com>
Date:   Thu, 16 Nov 2023 20:08:54 +0100
Message-ID: <CANH4o6MF=TCRX=FA+OFeDXffVq5rKLcaNt7ZFPbt8_FxjWyOVg@mail.gmail.com>
Subject: Re: Does NFSv4 close-to-open consistency work with server "async"
 mount open?
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Nov 16, 2023 at 1:30=E2=80=AFPM Benjamin Coddington <bcodding@redha=
t.com> wrote:
>
> On 16 Nov 2023, at 2:11, Martin Wege wrote:
>
> > Hello,
> >
> > Does NFSv4 close-to-open consistency on the client work with server
> > "async" mount open?
>
> Yes, I believe it should, but I am looking at knfsd code and I think it
> won't.

What does that mean? nfsd server bug?

>
> > We see several build errors here with parallel GNU Makefile update,
> > where one process writes a file, exists, and the next process doesn't
> > see all data (linker ar: file too short).
> > But if you manually look at it the files are OK, and completely written=
.
> >
> > What is this? NFSv4 client bug, NFSv4 server bug, admin error (async
> > breaking close-to-open consistency?
>
> Hard to say, a wire capture would show.  My guess is that the server's
> "async" disables the write gather in nfsd_vfs_write().

What is the correct option in Linux /etc/exports to enforce NFSv4
standard conformance?

> > Also, is close-to-open consistency guaranteed between different NFSv4 c=
lients?
>
> Yes.

How does it work in a NFSv4 client implementation?

Thanks,
Martin