Re: Locking issue between NFSv4 and SMB client

["bfields@fieldses.org" <bfields@fieldses.org>]

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.