Work on SMB3 persistent handles

[Christopher R. Hertel]

On 10/30/2017 11:31 AM, Albert Guo wrote:
> Hi Ralph,
> 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?

The model that Ralph and I (and others) discussed last September at the
Storage Developers Conference (SDC) was, indeed, coupled on CTDB.  I am sure
Ralph will correct me if I misstate, but as I understand it there was a
strong desire within the Samba Team to ensure that Samba itself--without any
FS-specific modifications--could provide Persistent Handle support.

As you know, I was advocating for a method that would allow vendor-specific
plug-ins.  It was agreed that we could set that as a longer-term goal.

This is, however, why I am keeping the protocol work separate from the
backing store modifications.  I believe that we can get the protocol piece
working nicely, add CTDB-based backing store, and then work on pluggable
modules.

> b. Do we still need to update multiple DBs with this approach? How to guarantee atomicity if updating multiple TDBs? Looks like your idea is to set a flag when the update for persistent state completes.

The design proposed at the SDC was to to augment the existing setup.  The
existing [C]TDB databases for locks, leases, and handles would still be
used.  Whenever a record associated with a Persistent Handle would be
changed, an *additional* database (a persistent [C]TDB database) would be
updated as well.  Only records related to a Persistent Handle would be
updated this way.

Whenever Persistent Handle data is retrieved, the persistent backing store
will be checked first.  If the entire cluster goes down, then when the
databases were re-opened the first step will be to clear the volatile
databases and then reload them from the persistent backing store, thus
allowing the handles to be re-opened as Persistent Handles and recovered.

I look forward to comments from others on the rest of your questions.

Chris -)-----

> “To maintain atomicity wrt to storing the FSA state, as the final step after successfully processing a persistent handle request, set the SHARE_MODE_FLAG_PERSISTENT_OPEN flag int struct share_mode_entry.flags.”
> 	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?
> 2. The second approach, i.e. “2.1.2 New database for persistent handles”
> 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?
> 
> Looking forward for you reply and thank you very much!
>