Received-SPF: pass (google.com: domain of linux-nfs+bounces-1053-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: <CAKAoaQniGNGuPm5CTTs3oJRuCH40HTt6K91nCAPRnt0tECxkBA@mail.gmail.com>
 <bce828afb68c973d684b3e179cf8d6ce39c8b9c3.camel@kernel.org>
 <39adc7fc114c6f8ea38fe7c846c322dab5fac907.camel@kernel.org>
 <CAKAoaQkdY-NOgWoVKN+oitTSFbmfC7fixoxDfXR0SF-6EJrEOw@mail.gmail.com>
 <5057fdb94f4d61661f9d13ccadb775a3a5bcdc92.camel@kernel.org>
 <CAAvCNcCC7xB1oWoSxaL269T62TuOYx64A+49fRoJTFJZ6xD+EA@mail.gmail.com>
 <6065a76f32face0fa5cf84a238bcb1f2eebec7b5.camel@kernel.org> <CAM5tNy6yW_zVCu-i_bG=Tp5wE7OTqcjdjCgCJUEhax-P6aWARA@mail.gmail.com>
In-Reply-To: <CAM5tNy6yW_zVCu-i_bG=Tp5wE7OTqcjdjCgCJUEhax-P6aWARA@mail.gmail.com>
From: Dan Shelton <dan.f.shelton@gmail.com>
Date: Fri, 12 Jan 2024 03:25:08 +0100
Message-ID: <CAAvCNcDrpAUQp8h1xEy4XtaN=GL4hvgTedhSi-bPTbD+7YfoiA@mail.gmail.com>
Subject: Re: NFSv4.1 mandatory locks working in Linux nfsd ?
To: Rick Macklem <rick.macklem@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>, Roland Mainz <roland.mainz@nrubsig.org>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 12 Jan 2024 at 03:13, Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Thu, Jan 11, 2024 at 5:25=E2=80=AFPM Jeff Layton <jlayton@kernel.org> =
wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph=
. Do not click links or open attachments unless you recognize the sender an=
d know the content is safe. If in doubt, forward suspicious emails to IThel=
p@uoguelph.ca.
> >
> >
> > On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <jlayton@kernel.org> wrote:
> > > >
> > > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > > On Thu, Jan 11, 2024 at 4:55=E2=80=AFPM Jeff Layton <jlayton@kern=
el.org> wrote:
> > > > > > On Thu, 2024-01-11 at 10:54 -0500, Jeff Layton wrote:
> > > > > > > On Sun, 2023-12-24 at 18:29 +0100, Roland Mainz wrote:
> > > > > > > > Are there any known issues with NFSv4.1 mandatory locking n=
fsd code in
> > > > > > > > the Linux 5.10.0-22-rt-amd64 kernel (technically the Debian=
 Bullseye
> > > > > > > > RT kernel) ? Is there any kernel or NFS test suite module w=
hich covers
> > > > > > > > NFSv4.1 client mandatory locking ?
> > > > > > >
> > > > > > > Linux doesn't support mandatory locking at all since 2021 [1]=
. The Linux
> > > > > > > NFS client and server therefore do not support v4.1 mandatory=
 locking.
> > > > > >
> > > > > > Forgot the footnote!
> > > > > >
> > > > > > [1]: https://patchwork.kernel.org/project/linux-fsdevel/patch/2=
0210820114046.69282-1-jlayton@kernel.org/
> > > > >
> > > > > OK, this is pretty bad in terms of interoperability.... ;-(
> > > > >
> > > > > What should a Windows NFSv4 client (Hummingbird, OpenText, Exceed=
,
> > > > > ms-nfs41-client, ...) do in this case ?
> > > > > It basically means that locking for these clients will fail if th=
e
> > > > > server does not support it... ;-(
> > > > >
> > > >
> > > > I think they have two choices:
> > > >
> > > > Learn to deal with advisory locking, or contribute some sort of (sa=
ne)
> > > > mandatory locking implementation to the Linux kernel.
> > >
> > > None of this will happen.
> > > 1. Advisory locking cannot be mapped to Windows mandatory locking. En=
d
> > > of story. They are incompatible. That is why the NFSv4 protocol had
> > > mandatory locking built in into the first place. That was the grand
> > > design and the grand dream. That is gone.
> Are you sure?
> What about the following (in the same compound RPC as the Read/Write
> operation):
> - if the byte range being read/written is not yet locked by the client/ta=
sk
>     Lock byte range using a lock_woner4 that represents the task doing
>     this Read/Write
> - do read/write
> - if Lock'd above, LockU the byte range
>
> As I understand it, the only difference between advisory vs mandatory
> byte range locking is that, for mandatory locking, the Read/Write will
> get a reply of NFS4ERR_LOCKED when a conflicting lock exists.
> --> For the above algorithm, the Lock operation will get a NFS4ERR_LOCKED
>       if a conflicting lock exists.
>      Isn't that at least roughly equivalent?
>
> There has always been problems w.r.t. mandatory locking in NFSv4.
> 1 - No way for the NFSv4 client to know if the server is implementing
>      mandatory locking. If you look back far enough, you'll find that RFC=
3010
>      had a flag in the Open reply that indicated "mandatory locking". It =
was
>      dropped for RFC3530 and nothing else was added to replace it.
> 2 - I could never see how write back data caching could be implemented in=
 the
>      client when the server is enforcing mandatory locking.
>      --> The write back fails with NFS4ERR_LOCKED. What does the client
>            do then?
>      I've concluded a client must either do write-through data caching or=
 byte
>      range lock all byte ranges of all files being write back data
> cached. Neither seem
>      reasonable to me.
>
> For a long time, I did have code in the FreeBSD NFSv4 server that
> could implement
> mandatory locking for NFSv4 clients only. (It is really only a check
> for a conflicting
> lock that is done by Read/Write.) I eventually got rid of it because
> no client wanted it.

Rick, welcome to https://github.com/kofemann/ms-nfs41-client or
https://www.opentext.co.uk/products-and-solutions/products/specialty-techno=
logies/connectivity/nfs-client-nfs-solo
I think both clients want that.

Dan
--=20
Dan Shelton - Cluster Specialist Win/Lin/Bsd