Hi!
----
Are there any known issues with NFSv4.1 mandatory locking nfsd 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 which covers
NFSv4.1 client mandatory locking ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
On Sun, 2023-12-24 at 18:29 +0100, Roland Mainz wrote:
> Hi!
>
> ----
>
> Are there any known issues with NFSv4.1 mandatory locking nfsd 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 which 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.
--
Jeff Layton <[email protected]>
On Thu, 2024-01-11 at 10:54 -0500, Jeff Layton wrote:
> On Sun, 2023-12-24 at 18:29 +0100, Roland Mainz wrote:
> > Hi!
> >
> > ----
> >
> > Are there any known issues with NFSv4.1 mandatory locking nfsd 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 which 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/[email protected]/
--
Jeff Layton <[email protected]>
On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
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... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
>
> 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.
A lot of those clients predate NFSv4, and they've had to deal with v3
locking for a long time which is also not usually mandatory. For the
first option, you might want to talk to the samba/cifs folks, since
they've done a fair bit of this sort of mapping of lock semantics and
might have thoughts about how to properly map windows locks onto POSIX
advisory locks. Note that windows locks are weird too for other reasons,
as they stack instead of split and merge, and I believe have to be
unstacked when you unlock them.
That approach (of course) won't block access from other (non-windows)
clients though that aren't setting locks, but it probably could be made
to at least get windows clients behaving with each other when sharing
files over NFS.
If you decide to go with the second option, then this is not really an
nfsd problem, per-se. Linux's nfsd only presents the semantics that the
underlying filesystem supports, so you'd need to build a (sane)
mandatory locking implementation for local access first, and then roll
the code for nfsd to deal with that. It'd be long slog, but it could be
done.
Cheers,
--
Jeff Layton <[email protected]>
On Thu, 11 Jan 2024 at 22:28, Roland Mainz <[email protected]> wrote:
>
> On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
>
> 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... ;-(
The Windows nfsd supports NFSv4 with mandatory locking. Or use SAMBA
like everyone else.
Honestly, while your msnfs41client for Windows is impressive, the
NFSv4 protocol is fighting a losing battle against SAMBA on every
other front than Linux. Even the HPC market is evaporating for NFS
since the day M$ came up with SMB DIRECT, as SMB over RDMA.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
>
> On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> >
> > 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
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> >
> > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > >
> > > 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.
Yep, pretty much. Samba does set VFS-layer advisory locks that (mostly)
correspond to the locks that SMB clients set, but it's really just a
best-effort sort of thing. It has to emulate the windows semantics
internally.
> 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.
>
Also, pretty much. With a general purpose OS like Linux, we try to avoid
this sort of emulation. We do have that for the share/deny locking that
happens during OPEN, but there was really no choice there since we
couldn't reasonably implement that in the VFS, and it was a required
part of the NFSv4 protocol.
Mandatory locking is optional so we can just opt-out.
> 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.
>
More or less. FWIW, here's the LWN article from when we decided to start
getting rid of mandatory locking in Linux:
https://lwn.net/Articles/667210/
No one used it. It was racy and there weren't great ways to fix that
that didn't slow down I/O.
--
Jeff Layton <[email protected]>
On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <[email protected]> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected].
>
>
> On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > >
> > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > > >
> > > > 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.
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/task
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 RFC3010
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
>
> Yep, pretty much. Samba does set VFS-layer advisory locks that (mostly)
> correspond to the locks that SMB clients set, but it's really just a
> best-effort sort of thing. It has to emulate the windows semantics
> internally.
>
> > 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.
> >
>
> Also, pretty much. With a general purpose OS like Linux, we try to avoid
> this sort of emulation. We do have that for the share/deny locking that
> happens during OPEN, but there was really no choice there since we
> couldn't reasonably implement that in the VFS, and it was a required
> part of the NFSv4 protocol.
>
> Mandatory locking is optional so we can just opt-out.
>
> > 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.
> >
>
> More or less. FWIW, here's the LWN article from when we decided to start
> getting rid of mandatory locking in Linux:
>
> https://lwn.net/Articles/667210/
>
> No one used it. It was racy and there weren't great ways to fix that
> that didn't slow down I/O.
> --
> Jeff Layton <[email protected]>
>
On Fri, 12 Jan 2024 at 03:13, Rick Macklem <[email protected]> wrote:
>
> On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <[email protected]> wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected].
> >
> >
> > On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > > >
> > > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > > > >
> > > > > 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.
> 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/task
> 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 RFC3010
> 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-technologies/connectivity/nfs-client-nfs-solo
I think both clients want that.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, Jan 12, 2024 at 2:24 AM Jeff Layton <[email protected]> wrote:
> On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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:
[snip]
> > 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.
> >
>
> Also, pretty much. With a general purpose OS like Linux, we try to avoid
> this sort of emulation. We do have that for the share/deny locking that
> happens during OPEN, but there was really no choice there since we
> couldn't reasonably implement that in the VFS, and it was a required
> part of the NFSv4 protocol.
>
> Mandatory locking is optional so we can just opt-out.
How can I test for that in a NFSv4.1 client implementation ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
On Thu, 11 Jan 2024 at 22:28, Roland Mainz <[email protected]> wrote:
>
> On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
>
> 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... ;-(
The NFSv4 server has to provide an emulation, as mandatory locking is
part of the NFSv4 protocol [1].
Although I am more, and more, and even more horrified that the once
beautiful NFSv4 design goal of a protocol for all platforms, as in
Windows, Unix, Linux, RTOS, ..., is rapidly degrading into a devolved
Linux-centric network fs, something 9p already covers, while
SMBFS/CIFS have completely taken over the market for cross-platform
network filesystems.
RIP NFSv4 ?!
[1]: <sarcasm>Of course the next NFS RFC will declare NFSv4 mandatory
locking as "obsolete", as interoperability is already covered by
SMB/CIFS and 9p</sarcasm>
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Thu, Jan 11, 2024 at 6:25 PM Dan Shelton <[email protected]> wrote:
>
> On Fri, 12 Jan 2024 at 03:13, Rick Macklem <[email protected]> wrote:
> >
> > On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <[email protected]> wrote:
> > >
> > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected].
> > >
> > >
> > > On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > > > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > > > >
> > > > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > > > > >
> > > > > > 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.
> > 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/task
> > 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 RFC3010
> > 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-technologies/connectivity/nfs-client-nfs-solo
> I think both clients want that.
Well, 20 years ago I beta tested the Hummingbird client (I'm surprised it is
still a product, since I haven't seen those guys at a bakeathon in a long time).
ack then, it was basically a port of their NFSv3 client and I do not recall that
it needed mandatory locking (or other features you have asked about, such
as named attributes and system/hidden attributes), but it has been 20years.
I wonder if they ever upgraded it to NFSv4.1?
As for the CITI code, it was meant to be a prototype and until recently seemed
to be dormant since work stopped on it at least 10years ago.
The short version is "Since Microsoft never adopted NFSv4 as an alternative
to Cifs/SMB, there is no significant demand for these features.
If you wanted a server that does mandatory locking, Solaris might?
(There used to be some weird combination of mode bits that meant
"mandatory locking" in Solaris. set_gid set and group_exec cleared,
or something like that. The problem is that a chmod could change this
at any time. I think that is why the Open flag that indicated mandatory
locking in RFC3010 got dropped for RFC3530.)
I proposed a "mandatory locking" attribute along with a few other
new attributes for NFSv4.2 in an IETF personal draft, but there did not
seem to be any interest, so I ditched it.
As far as I know, the only way for a client to know if mandatory
locking is being done by the server is something like:
- Open a file
- Apply a write lock using a different lock_owner4
- Attempt to read the file.
--> If the read replies NFS4ERR_LOCKED, then the server is
applying mandatory locking.
Of course, there is no guarantee the same semantics will apply
to other files nor that the semantics will not change for that file.
I used to email [email protected] 20 years ago about this, but I
gave up after a while, since no one seemed interested.
(Again, the "if Microsoft doesn't care, the vendors don't care"
principal.)
rick
ps: A Solaris server might also do named attributes?
>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, 12 Jan 2024 at 20:45, Rick Macklem <[email protected]> wrote:
>
> On Thu, Jan 11, 2024 at 6:25 PM Dan Shelton <[email protected]> wrote:
> >
> > On Fri, 12 Jan 2024 at 03:13, Rick Macklem <[email protected]> wrote:
> > >
> > > On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <[email protected]> wrote:
> > > >
> > > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected].
> > > >
> > > >
> > > > On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > > > > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > > > > >
> > > > > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > > > > > >
> > > > > > > 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.
> > > 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/task
> > > 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 RFC3010
> > > 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-technologies/connectivity/nfs-client-nfs-solo
> > I think both clients want that.
> Well, 20 years ago I beta tested the Hummingbird client (I'm surprised it is
> still a product, since I haven't seen those guys at a bakeathon in a long time).
> ack then, it was basically a port of their NFSv3 client and I do not recall that
> it needed mandatory locking (or other features you have asked about, such
> as named attributes and system/hidden attributes), but it has been 20years.
> I wonder if they ever upgraded it to NFSv4.1?
>
> As for the CITI code, it was meant to be a prototype and until recently seemed
> to be dormant since work stopped on it at least 10years ago.
New binaries with new features and bug fixes every month does not look
"dormant" to me:
https://sourceforge.net/p/ms-nfs41-client/mailman/message/58718627/
>
> The short version is "Since Microsoft never adopted NFSv4 as an alternative
> to Cifs/SMB, there is no significant demand for these features.
Microsoft is selling a NFSv4 SERVER, actually with support and bug
fixes. Hell knows why they abandoned the CITI project
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, Jan 12, 2024 at 4:09 PM Dan Shelton <[email protected]> wrote:
>
> On Fri, 12 Jan 2024 at 20:45, Rick Macklem <[email protected]> wrote:
> >
> > On Thu, Jan 11, 2024 at 6:25 PM Dan Shelton <[email protected]> wrote:
> > >
> > > On Fri, 12 Jan 2024 at 03:13, Rick Macklem <[email protected]> wrote:
> > > >
> > > > On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <[email protected]> wrote:
> > > > >
> > > > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email protected].
> > > > >
> > > > >
> > > > > On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote:
> > > > > > On Thu, 11 Jan 2024 at 23:53, Jeff Layton <[email protected]> wrote:
> > > > > > >
> > > > > > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote:
> > > > > > > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <[email protected]> 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 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 which 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/[email protected]/
> > > > > > > >
> > > > > > > > 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.
> > > > 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/task
> > > > 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 RFC3010
> > > > 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-technologies/connectivity/nfs-client-nfs-solo
> > > I think both clients want that.
> > Well, 20 years ago I beta tested the Hummingbird client (I'm surprised it is
> > still a product, since I haven't seen those guys at a bakeathon in a long time).
> > ack then, it was basically a port of their NFSv3 client and I do not recall that
> > it needed mandatory locking (or other features you have asked about, such
> > as named attributes and system/hidden attributes), but it has been 20years.
> > I wonder if they ever upgraded it to NFSv4.1?
> >
> > As for the CITI code, it was meant to be a prototype and until recently seemed
> > to be dormant since work stopped on it at least 10years ago.
>
> New binaries with new features and bug fixes every month does not look
> "dormant" to me:
> https://sourceforge.net/p/ms-nfs41-client/mailman/message/58718627/
>
I did say "until recently".
> >
> > The short version is "Since Microsoft never adopted NFSv4 as an alternative
> > to Cifs/SMB, there is no significant demand for these features.
>
> Microsoft is selling a NFSv4 SERVER, actually with support and bug
> fixes. Hell knows why they abandoned the CITI project
Yea, I was thinking of the desktop client case. (I actually think they have
some sort of NFSv4 client in Windows server as well?)
rick
>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd