Work on SMB3 persistent handles

Jeremy Allison jra at samba.org
Fri Nov 17 23:07:34 UTC 2017


On Fri, Nov 17, 2017 at 11:40:42PM +0100, Ralph Böhme wrote:
> On Thu, Nov 16, 2017 at 02:55:41PM -0800, Jeremy Allison wrote:
> > On Thu, Nov 16, 2017 at 10:19:03PM +0100, Ralph Böhme via samba-technical wrote:
> > > Hi Albert,
> > > 
> > > On Thu, Nov 09, 2017 at 07:46:29AM +0000, Albert Guo wrote:
> > > > > 2. The second approach, i.e. “2.1.2 New database for persistent handles”
> > > > >
> > > > > After some more tinkering I came to the conclustion that this approach doesn't
> > > > > work. I've removed it from the design doc.
> > > 
> > > > Could you give me a bit more explanation on why you think this approach
> > > > doesn’t work?
> > > 
> > > Because storing the (persistent) handle state is only one part, the other one is
> > > the FSA state.
> > > 
> > > Without extensive filesystem support with a lower level OS API for persistent
> > > handles and a complete redesign of our durable and future persistent handle
> > > support on top of that, we have to implement the required FSA state guarantees
> > > in Samba and in clustered Samba.
> > 
> > When we design the API for the FSA state guarantees for Samba/Clustered Samba
> > we need to make this pluggable (maybe via VFS calls) in order to allow OEMs
> > with a filesystem that can make these guarantees directly to call into their
> > filesystems, whilst the default is to call our own backends.
> 
> show me the filesystem and show me the lower level API, then we'll see. Until
> then this will be implemented in dbwrap with some protocol sugar. :)

Fair enough as a first implementation. But I think ultimately we'll
need to wrap this in a pluggable API.

But right now I don't know *exactly* what that API should be, so
working code will trump everything first (as it should :-).



More information about the samba-technical mailing list