On Fri, Sep 24, 2021 at 09:36:46AM -0700, Jeremy Allison wrote: > On Fri, Sep 24, 2021 at 04:13:23AM +0000, Trond Myklebust wrote: > >On Fri, 2021-09-24 at 05:46 +0200, Ralph Boehme wrote: > >>Am 24.09.21 um 05:35 schrieb Trond Myklebust: > >>> Not if you set the "kernel oplocks" parameter in the smb.conf file. > >>> We > >>> just added support for this in the Linux 5.14 kernel NFSv4 client. > >>> > >>> Now that said, "kernel oplocks" will currently only support basic > >>> level > >>> I oplocks, and cannot support level II or leases. According to the > >>> smb.conf manpage, this is due to some incompleteness in the current > >>> VFS > >>> lease implementation. > >>> > >>> I'd love to get some more info from the Samba team about what is > >>> missing from the kernel lease implementation that prevents us from > >>> implementing these more advanced oplock/lease features. From the > >>> description in Microsoft's docs, I'm pretty sure that NFSv4 > >>> delegations > >>> should be able to provide all the guarantees that are required. > >> > >>leases can be shared among file handles. When someone requests a > >>lease > >>he passes a cookie. Then when he opens the same file with the same > >>cookie the lease is not broken. > > > >Right, but that is easily solved in user space by having the cookie act > >as a key that references the file descriptor that holds the lease. This > >is how we typically implement NFSv4 delegations as well. > > How does this work in multi-process situations ? > When you say "file descriptor", if the fd was passed > between processes would the lease state transfer ? Yes, the lease is associated with the "file description"/struct file, so for example you should be able to F_UNLCK it from the new process. --b.