On Thu, Jan 11, 2024 at 6:25 PM Dan Shelton <dan.f.shelton@xxxxxxxxx> wrote: > > On Fri, 12 Jan 2024 at 03:13, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > > > 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, welcome to https://github.com/kofemann/ms-nfs41-client or > https://www.opentext.co.uk/products-and-solutions/products/specialty-technologies/connectivity/nfs-client-nfs-solo > I think both clients want that. Well, 20 years ago I beta tested the Hummingbird client (I'm surprised it is still a product, since I haven't seen those guys at a bakeathon in a long time). ack then, it was basically a port of their NFSv3 client and I do not recall that it needed mandatory locking (or other features you have asked about, such as named attributes and system/hidden attributes), but it has been 20years. I wonder if they ever upgraded it to NFSv4.1? As for the CITI code, it was meant to be a prototype and until recently seemed to be dormant since work stopped on it at least 10years ago. The short version is "Since Microsoft never adopted NFSv4 as an alternative to Cifs/SMB, there is no significant demand for these features. If you wanted a server that does mandatory locking, Solaris might? (There used to be some weird combination of mode bits that meant "mandatory locking" in Solaris. set_gid set and group_exec cleared, or something like that. The problem is that a chmod could change this at any time. I think that is why the Open flag that indicated mandatory locking in RFC3010 got dropped for RFC3530.) I proposed a "mandatory locking" attribute along with a few other new attributes for NFSv4.2 in an IETF personal draft, but there did not seem to be any interest, so I ditched it. As far as I know, the only way for a client to know if mandatory locking is being done by the server is something like: - Open a file - Apply a write lock using a different lock_owner4 - Attempt to read the file. --> If the read replies NFS4ERR_LOCKED, then the server is applying mandatory locking. Of course, there is no guarantee the same semantics will apply to other files nor that the semantics will not change for that file. I used to email nfsv4@xxxxxxxx 20 years ago about this, but I gave up after a while, since no one seemed interested. (Again, the "if Microsoft doesn't care, the vendors don't care" principal.) rick ps: A Solaris server might also do named attributes? > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd
