All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Allison <jra@samba.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Volker.Lendecke@sernet.de, samba-technical@lists.samba.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	devel@lists.nfs-ganesha.org
Subject: Re: Better interop for NFS/SMB file share mode/reservation
Date: Wed, 6 Mar 2019 13:07:43 -0800	[thread overview]
Message-ID: <20190306210743.GE19279@jra3> (raw)
In-Reply-To: <1ade4724a4e505baf7b7c23a76e44d58b931da1f.camel@kernel.org>

On Wed, Mar 06, 2019 at 03:31:08PM -0500, Jeff Layton wrote:
> On Wed, 2019-03-06 at 10:11 -0500, J. Bruce Fields wrote:
> > On Tue, Mar 05, 2019 at 04:47:48PM -0500, J. Bruce Fields wrote:
> > > On Thu, Feb 14, 2019 at 04:06:52PM -0500, J. Bruce Fields wrote:
> > > > After this:
> > > > 
> > > > 	https://marc.info/?l=linux-nfs&m=154966239918297&w=2
> > > > 
> > > > delegations would no longer conflict with opens from the same tgid.  So
> > > > if your threads all run in the same process and you're willing to manage
> > > > conflicts among your own clients, that should still allow you to do
> > > > multiple opens of the same file without giving up your lease/delegation.
> > > > 
> > > > I'd be curious to know whether that works with Samba's design.
> > > 
> > > Any idea whether that would work?
> > > 
> > > (Easy?  Impossible?  Possible, but realistically the changes required to
> > > Samba would be painful enough that it'd be unlikely to get done?)
> > 
> > Volker reminds me off-list that he'd like to see Ganesha and Samba work
> > out an API in userspace first before commiting to a user<->kernel API.
> > 
> > Jeff, wasn't there some work (on Ceph maybe?) on a userspace delegation
> > API?  Is that close to what's needed?
> > 
> 
> Here's the C headers for that stuff:
> 
>     https://github.com/ceph/ceph/blob/7ba6bece4187eda5d05a9b84211fe6ba8dd287bd/src/include/cephfs/libcephfs.h#L1734
> 
> It's simple enough and works for us in ganesha, and I think we can
> probably adapt it to samba without too much difficulty. The callback
> doesn't seem like it'll do for a kernel API though -- you'd almost
> certainly need to do something different there (signals? inotify?).

SMB3 leases have R/RW and Handle-based leases.

Handle leases allow multiple opens of the same pathname
that get different handles to share the lease, allowing
a client redirector to delay opens or closes locally
so long as it has a handle lease.

Here are the semantics:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/d8df943d-6ad7-4b30-9f58-96ae90fc6204

I'm not sure a simple file-descriptor based API is
enough for us. Can he have a uuid or token based
API instead where the server can chose what fd's
to cover with a token ?

  reply	other threads:[~2019-03-06 21:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 11:20 Better interop for NFS/SMB file share mode/reservation Amir Goldstein
2019-02-08 13:10 ` Jeff Layton
2019-02-08 14:45   ` Amir Goldstein
2019-02-08 15:50     ` J. Bruce Fields
2019-02-08 20:02       ` Amir Goldstein
2019-02-08 20:16         ` J. Bruce Fields
2019-02-08 20:31           ` Amir Goldstein
2019-02-14 20:51             ` J. Bruce Fields
2019-02-15  7:31               ` Amir Goldstein
2019-02-15 20:09                 ` J. Bruce Fields
2019-02-08 22:12         ` Jeremy Allison
2019-02-09  4:04           ` Amir Goldstein
2019-02-14 21:06             ` J. Bruce Fields
2019-03-05 21:47               ` J. Bruce Fields
2019-03-06  7:09                 ` Amir Goldstein
2019-03-06 15:17                   ` J. Bruce Fields
2019-03-06 15:37                     ` [NFS-Ganesha-Devel] " Frank Filz
2019-03-08 21:38                       ` 'J. Bruce Fields'
2019-03-08 21:53                         ` Frank Filz
2019-03-06 15:11                 ` J. Bruce Fields
2019-03-06 20:31                   ` Jeff Layton
2019-03-06 21:07                     ` Jeremy Allison [this message]
2019-03-06 21:25                       ` Ralph Böhme
2019-03-07 11:03                         ` Stefan Metzmacher
2019-03-07 16:47                           ` Simo
2019-04-25 18:11                           ` Amir Goldstein
2019-05-24  7:12                             ` Amir Goldstein
2019-05-24 13:15                               ` Ralph Boehme
2019-05-24 15:07                               ` J. Bruce Fields
2019-03-06 21:55                       ` Jeff Layton
2019-02-08 16:03     ` Jeff Layton
2019-02-08 16:28       ` Jeffrey Layton
     [not found]       ` <CAOQ4uxgQsRaEOxz1aYzP1_1fzRpQbOm2-wuzG=ABAphPB=7Mxg@mail.gmail.com>
     [not found]         ` <20190426140023.GB25827@fieldses.org>
     [not found]           ` <CAOQ4uxhuxoEsoBbvenJ8eLGstPc4AH-msrxDC-tBFRhvDxRSNg@mail.gmail.com>
     [not found]             ` <20190426145006.GD25827@fieldses.org>
     [not found]               ` <e69d149c80187b84833fec369ad8a51247871f26.camel@kernel.org>
2019-04-27 20:16                 ` Amir Goldstein
2019-04-28 12:09                   ` Jeff Layton
2019-04-28 13:45                     ` Amir Goldstein
2019-04-28 15:06                       ` Trond Myklebust
2019-04-28 22:00                         ` Amir Goldstein
2019-04-28 22:08                           ` Trond Myklebust
2019-04-28 22:33                             ` Amir Goldstein
2019-04-29  0:57                               ` Trond Myklebust
2019-04-29 11:42                                 ` Amir Goldstein
2019-04-29 13:10                                   ` Trond Myklebust
2019-04-29 20:29                                 ` Jeff Layton
2019-04-29 22:33                                   ` Pavel Shilovskiy
2019-04-30  0:31                                     ` Amir Goldstein
2019-04-30  8:12                                       ` Uri Simchoni
2019-04-30  9:22                                         ` Amir Goldstein
2019-02-11  5:31     ` ronnie sahlberg

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=20190306210743.GE19279@jra3 \
    --to=jra@samba.org \
    --cc=Volker.Lendecke@sernet.de \
    --cc=amir73il@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=devel@lists.nfs-ganesha.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=samba-technical@lists.samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.