Work on SMB3 persistent handles

[Ralph Böhme]

Hi Albert,

On Mon, Oct 30, 2017 at 04:31:40PM +0000, Albert Guo wrote:
> Your design doc is really very helpful! 
> I got server questions:
> 1. The first approach, i.e. “2.1.1 New dbwrap backend with support for per record persistency”
> a. Is this approach coupled with CTDB?

No. It works with and without ctdb.

> b. Do we still need to update multiple DBs with this approach?

Sure.

> How to guarantee atomicity if updating multiple TDBs? Looks like your idea is
> to set a flag when the update for persistent state completes.

To get something managable it would be helpful to merge locking.tdb and
brlock.tdb, cf

https://lists.samba.org/archive/samba-technical/2017-October/123583.html
https://lists.samba.org/archive/samba-technical/2017-November/123628.html

Both tdbs merged we just have one store of the persistent FSA state in the
locking.tdb.

> Does that mean if this flag isn’t set for a “persistent file handle” during
> recovery, we should throw away all the records that’s associated with this
> file handle?

Not quite. We need a reliable cleanup like the scavenger for durable opens. I
haven't yet really turned to this problem.

> 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.

> My understanding is we just create a single DB for storing all states related
> to persistent handles. Correct?  One question came to my mind is that what’s
> the correct behavior if updating to this persistent database fails? Should we
> failback to durable file handles?  With this approach, looks like we can
> maintain a very simple interface between the protocol and the backing store of
> persistent handles.
> 
> 3. I’m confused when you say below fields are not needed for persistent
> handles: “Looking up MS-SMB2 for uses to these elements show that none of them
> is required for persistent handles, because:
> 
> Open.DesiredAccess: not used in MS-SMB2, not needed
> Open.ShareMode: not used in MS-SMB2, not needed
> Open.FileAttributes: not used in MS-SMB2, not needed
> Open.CreateDisposition: not used in MS-SMB2, not needed
> …”
> 
> It’s clearly stated in MS-SMB2 that all of the above fields are included in
> SMB2 Create request, why are they not needed?

It's not needed at the file-handle layer in smbXsrv_open_global.tdb.

-slow

-- 
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/