Merge brlock.tdb and locking.tdb

Ralph Böhme slow at
Fri Dec 7 15:05:29 UTC 2018

On Sun, Oct 29, 2017 at 08:39:02PM +0100, Volker Lendecke via samba-technical wrote:
>On Sun, Oct 29, 2017 at 06:25:54PM +0100, David Disseldorp via samba-technical wrote:
>> On Sun, 29 Oct 2017 12:29:08 +0100, Ralph Böhme via samba-technical wrote:
>> > Unless I'm missing something, the record key is the same, we could add the brl data
>> > to the struct share_mode_data IDL definition and update the brlock code to use a
>> > different backing store.
>> >
>> > This consolidation could be helpful in the implementation of a persistent
>> > handles backing store.
>> >
>> > Anyone?
>> Sounds like a good idea to me.
>One argument for keeping brlock.tdb is the fact that we might have to
>read it MUCH more often to implement mandatory byte range
>locking. You don't want to parse a potentially large and complex
>locking.tdb record for every read or write request.

So what about putting the brlock record as raw blob before the share_mode_data 
into locking.tdb, ie

struct locking_tdb_record {
        uint32 num_brlocks;
        [size_is(num_brlocks)] struct lock_struct brlocks[];

        struct share_mode_data share_mode;

Therein only share_mode is NDR encoded, num_brlocks and brlocks[] is not.

With dbwrap_record_storev() to avoid memcpy this should fly. Eg for any SMB2 
CREATE that requests an oplock or lease we call file_has_brlocks(). Or avoids 
the extra record fetch in update_num_read_oplocks().

Plus: avoids expensive persistent stores in the future with persistent handles.



Ralph Boehme, Samba Team      
Samba Developer, SerNet GmbH
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

More information about the samba-technical mailing list