linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "bfields@fieldses.org" <bfields@fieldses.org>,
	"jra@samba.org" <jra@samba.org>,
	"dai.ngo@oracle.com" <dai.ngo@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>
Subject: Re: Locking issue between NFSv4 and SMB client
Date: Fri, 24 Sep 2021 03:35:38 +0000	[thread overview]
Message-ID: <48b3a41e2dbea7948b0df3fea002208a273409fd.camel@hammerspace.com> (raw)
In-Reply-To: <20210923215056.GH18334@fieldses.org>

On Thu, 2021-09-23 at 17:50 -0400, Bruce Fields wrote:
> On Thu, Jul 15, 2021 at 04:45:22PM -0700, dai.ngo@oracle.com wrote:
> > Hi Bruce,
> 
> Oops, sorry for neglecting this.
> 
> > I'm doing some locking testing between NFSv4 and SMB client and
> > think there are some issues on the server that allows both clients
> > to lock the same file at the same time.
> 
> It's not too surprising to me that getting consistent locks between
> the
> two would be hard.
> 
> Did you get any review from a Samba expert?  I seem to recall it
> having
> a lot of options, and I wonder if it's configured correctly for this
> case.
> 
> It sounds like Samba may be giving out oplocks without getting a
> lease
> from the kernel.
> 

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.

Jeremy, would you be able to elaborate on this topic?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  parent reply	other threads:[~2021-09-24  3:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 23:45 Locking issue between NFSv4 and SMB client dai.ngo
2021-07-15 23:47 ` dai.ngo
2021-09-23 21:50 ` Bruce Fields
2021-09-23 22:39   ` dai.ngo
2021-09-24  0:51     ` Jeremy Allison
2021-09-24  0:56       ` Bruce Fields
2021-10-07 17:03     ` dai.ngo
2021-10-07 17:38       ` dai.ngo
2021-10-11 16:21         ` Bruce Fields
2021-09-24  3:35   ` Trond Myklebust [this message]
2021-09-24  3:46     ` Ralph Boehme
2021-09-24  4:13       ` Trond Myklebust
2021-09-24  4:55         ` Ralph Boehme
2021-09-24 16:36         ` Jeremy Allison
2021-09-24 16:45           ` bfields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48b3a41e2dbea7948b0df3fea002208a273409fd.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=bfields@fieldses.org \
    --cc=dai.ngo@oracle.com \
    --cc=jra@samba.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).