Work on SMB3 persistent handles

[Albert Guo]

Hi Ralph
    > 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.
 Could you give me a bit more explanation on why you think this approach doesn’t work?  This was attractive to me as well on an initial thought because it really keeps the interface between Samba and backend storage radically simple.

-- 
Thanks!
Albert
 

On 11/8/17, 6:36 AM, "Ralph Böhme" <slow at samba.org> wrote:

    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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.samba.org_archive_samba-2Dtechnical_2017-2DOctober_123583.html&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpZz2HyaI5SCm3Td3B2EHA&m=oajnaRk4e-b4sNByrFCveWF2ie9FyKHILo1_kyPHy74&s=Yb-idzKhZOml-27g-X4X4qOUQPlNkqJT9UhuCi3HrIA&e=
    https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.samba.org_archive_samba-2Dtechnical_2017-2DNovember_123628.html&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpZz2HyaI5SCm3Td3B2EHA&m=oajnaRk4e-b4sNByrFCveWF2ie9FyKHILo1_kyPHy74&s=MnP4MvaJqpSuPZjbmL-75U3fo1MiswZcf_DDTSO4pjU&e=
    
    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://urldefense.proofpoint.com/v2/url?u=https-3A__samba.org_&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpZz2HyaI5SCm3Td3B2EHA&m=oajnaRk4e-b4sNByrFCveWF2ie9FyKHILo1_kyPHy74&s=akBJMlzvHkZwTTwIcNwnIScz-4zzk-oFyYbDUEqjniw&e=
    Samba Developer, SerNet GmbH   https://urldefense.proofpoint.com/v2/url?u=https-3A__sernet.de_en_samba_&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wpZz2HyaI5SCm3Td3B2EHA&m=oajnaRk4e-b4sNByrFCveWF2ie9FyKHILo1_kyPHy74&s=yWWgBRyPzURqzdEylitMPE0VLe4GFxjyW81So67jslY&e=