On Thu, 11 Jan 2024 at 23:53, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Thu, 2024-01-11 at 22:27 +0100, Roland Mainz wrote: > > On Thu, Jan 11, 2024 at 4:55 PM Jeff Layton <jlayton@xxxxxxxxxx> 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/20210820114046.69282-1-jlayton@xxxxxxxxxx/ > > > > 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
