Work on SMB3 persistent handles

Albert Guo aguo at
Wed Oct 25 16:48:22 UTC 2017

Hi Chris,

Are you going to implement persistent file handles based on some interfaces provided by cluster file system or based on CTDB?

VMware only concerns about the former one.

If the cluster file system provides a small fast POSIX file system which is used to store the TDBs, would that be sufficient for supporting persistent file handles?

As regard to the fast POSIX file system, it could be a memory based file system which is replicated to at least 2 nodes, or it can be on NVMe or SSD etc.

In our architecture, different nodes serve different shares, so the same TDB won’t be accessed/competed by different hosts simultaneously. Hopefully the performance won’t be very bad.

In order to ensure any SMB request are processed transactionally. i.e. Samba can recover itself to a consistent state whenever one node crashes. I think we’ll need the following guarantee for entries related to persistent file handles:

·          Update to a single TDB is transactional.  Looks like current TDB only support a single transaction, making it transactional might downgrade its performance dramatically.

·          It’s possible to update multiple TDBs when process a single SMB request like open. We need to ensure the update to those multiple TDBs are transactional as well. Probably we may need to introduce an assistant TDB for ensuring the transactional semantic of processing a single SMB request.





On 10/26/17, 12:09 AM, "Albert Guo" <aguo at> wrote:

    Hi Chris,

    I’ve already checked out your code from the CA branch and played with it.

    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.

    The purpose of the POC is to identify the gaps we have for supporting persistent file handles.

    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

    2.                Disable the code for checking whether server_id is disconnected.

    I assume you’re trying to store server_id when Samba deamon is shutdown so that persistent file handle can be reconnected successfully?




    On 10/25/17, 2:17 AM, "Christopher R. Hertel" <crh at> wrote:

        On 10/24/2017 10:29 AM, Michael Adam wrote:



        > Chris, feel free to use / merge / discard as you see fit.

        > (I'd guess Metze would agree).

        I will do my best to merge the solutions so that they can be applied against


        > Also I'd be interested to see any WIP patches of yours,

        > no matter how incomplete.


        That code is testable as-is.  It has no negative impact on the rest of

        Samba, and succeeds at negotiating Persistent Handles (per Session) and

        Continuous Availability (per share).  It does not yet have the changes

        needed to actually store the Persistent Handle data in a recoverable way,

        but that's not necessary for initial testing.

        Persistent Handles should be recoverable even without persistent backing

        store.  In a network outage, a Persistent Handle would work the same way as

        a Durable Handle, so a test that simply drops the TCP connection and then

        reconnects should get correct Persistent Handle behavior.

        I think that Ralph had some smbtorture code that could do some of this testing.

        What I am working on now is making sure that the code in my repository

        provides a correct response to a Persistent Handle reconnect.  If I can get

        that part working, then the only part missing will be the actual persistent

        data storage/recovery.

        Chris -)-----

More information about the samba-technical mailing list