Merge brlock.tdb and locking.tdb

[Jeremy Allison]

On Fri, Dec 07, 2018 at 04:05:29PM +0100, Ralph Böhme wrote:
> 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?

That sounds like a plan. So in the locking code we just read
the first num_brlocks * sizeof(struct lock_struct) bytes, and
just add in the (untouched) share_mode_data afterwards on write.

Might simplify things a bit.

Numbers (benchmarks:-) however, would be welcome !