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. 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 <jlayton@xxxxxxxxxx>
