Merge brlock.tdb and locking.tdb

[Ralph Böhme]

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.

Thoughts?

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46