On Fri, 12 Jan 2024 at 20:45, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > 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. New binaries with new features and bug fixes every month does not look "dormant" to me: https://sourceforge.net/p/ms-nfs41-client/mailman/message/58718627/ > > The short version is "Since Microsoft never adopted NFSv4 as an alternative > to Cifs/SMB, there is no significant demand for these features. Microsoft is selling a NFSv4 SERVER, actually with support and bug fixes. Hell knows why they abandoned the CITI project Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd
