On Thu, 11 Jan 2024 at 22:28, Roland Mainz <roland.mainz@xxxxxxxxxxx> 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... ;-( 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 <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
