Work on SMB3 persistent handles

Albert Guo aguo at
Mon Oct 30 16:31:40 UTC 2017

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?
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.
“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!


On 10/27/17, 1:27 AM, "Ralph Böhme" <slow at> wrote:

    Hi folks,
    On Wed, Oct 25, 2017 at 04:09:21PM +0000, Albert Guo via samba-technical wrote:
    > I made a POC based on your git repository with some hack.  This is test I did:
    > 1.	Copy a large file to a CA enabled share from Windows 2012 R2 client
    > 2.	Restart Samba daemons
    > The persistent file handle is reconnected successfully, and the file copy
    > continues without any error.
    hooray! :)
    Fwiw I've been exploring the design space for fur in my spare time and also took
    some notes on possible designs for the persistent storage layer and APIs. You
    can find my current design doc here:
    git branch: <>
    git commit: <>
    as txt: <>
    as html: <>
    The links are a bit broken in the text version.
    The branch also has a bunch of torture tests for various aspects of persistent
    handles as well as some wip patches for the SMB2 frontend and the FSA
    subsystems. But most of that stuff is more akind of taking notes. Some stuff is
    from going through the Simplivity patchset (see below) and splitting it up into
    microcommits [1].
    For the storage backend I'm currently leaning towards the "2.1.2 New database
    for persistent handles" design and will start prototyping in my spare time. I'm
    only making slow progress as there's just too much other stuff that wants my
    attention. :)
    > The purpose of the POC is to identify the gaps we have for supporting persistent file handles.
    For upstream we mostly needed a proper storage layer that also works in the
    clustered case.
    One important thing that may not be obvious is that you have to protect
    disconnected persistent handles from contenting opens, cf MS-SMB2 and Though the latter is currently incomplete and will be updated my MS in
    the future explaining how to deal with lease breaks and disconnected PHs. I can
    share the details if you like, I haven't yet added this to my design doc
    > I attached my patch in the attachment. The patch is very simple:
    > 1. Remove TDB_CLEAR_IF_FIRST from open path of locking.tdb and
    >    smbXsrv_open_global.tdb
    Without adding transactions this has the risk of corrupting the databases in the
    event of a crash. Adding transcations has performance implications. Iirc patches
    for persistent handles were submitted to the mailing list, directly or
    indirectly, at least once. I have a munged version of the persistent handle
    patchset from Simplivity here:
    [1] <>
    Ralph Boehme, Samba Team
    Samba Developer, SerNet GmbH

More information about the samba-technical mailing list