On Fri, 2024-01-12 at 01:44 +0100, Dan Shelton wrote: > 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. 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 <jlayton@xxxxxxxxxx>
