Work on SMB3 persistent handles

[Michael Adam]

On 2017-10-30 at 12:04 -0500, Christopher R. Hertel wrote:
> 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.

This is true, but to my understanding as a new dbwrap-backend it
will not be exclusively coupled with CTDB. In a clustered case
(samba+ctdb) it would use CTDB, in a non-clustered case, plain TDB.

Cheers - Michael


> 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!
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20171031/1d800fed/signature.sig>