On Thu, Jan 11, 2024 at 5:25 PM Jeff Layton <jlayton@xxxxxxxxxx> 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 IThelp@xxxxxxxxxxx. > > > 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. 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 <jlayton@xxxxxxxxxx> >
