Received-SPF: pass (google.com: domain of linux-nfs+bounces-1050-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
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>
In-Reply-To: <5057fdb94f4d61661f9d13ccadb775a3a5bcdc92.camel@kernel.org>
From: Dan Shelton <dan.f.shelton@gmail.com>
Date: Fri, 12 Jan 2024 01:44:08 +0100
Message-ID: <CAAvCNcCC7xB1oWoSxaL269T62TuOYx64A+49fRoJTFJZ6xD+EA@mail.gmail.com>
Subject: Re: NFSv4.1 mandatory locks working in Linux nfsd ?
To: Jeff Layton <jlayton@kernel.org>
Cc: 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 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@kernel.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 nfsd co=
de in
> > > > > the Linux 5.10.0-22-rt-amd64 kernel (technically the Debian Bulls=
eye
> > > > > RT kernel) ? Is there any kernel or NFS test suite module which c=
overs
> > > > > 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 locki=
ng.
> > >
> > > Forgot the footnote!
> > >
> > > [1]: https://patchwork.kernel.org/project/linux-fsdevel/patch/2021082=
0114046.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 the
> > server does not support it... ;-(
> >
>
> I think they have two choices:
>
> Learn to deal with advisory locking, or contribute some sort of (sane)
> mandatory locking implementation to the Linux kernel.

None of this will happen.
1. Advisory locking cannot be mapped to Windows mandatory locking. End
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.
2. No one is going to implement a giant set of code just so that SAMBA
and NFSv4 can work. SAMBA has a builtin emulation so mandatory locking
works between Windows clients, ignoring the Linux side and Linux
advisory locking completely.

The only option is option three: NFSv4 for Windows will become a 3rd
class glorified FTP replacement with no functional locking. Just for
copying files around. End of story.

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