[RFC] Switch on tdb2 API by default?

Rusty Russell rusty at rustcorp.com.au
Thu Sep 22 21:53:17 MDT 2011


On Thu, 22 Sep 2011 07:52:25 -0400, simo <idra at samba.org> wrote:
> On Thu, 2011-09-22 at 10:38 +0930, Rusty Russell wrote: 
> > Hi all!
> > 
> >    The TDB2 code (ie. --enable-tdb2) runs in TDB1 mode by default now
> > (there's a tdb_compat shim which inserts the TDB_VERSION1 flag unless
> > the env var TDB_COMPAT_USE_TDB2 is set).
> > 
> >    So I'd like to make --enable-tdb2 the default now.  That way we can
> > test the tdb2 API, and have a run-time flag to enable the tdb2 on-disk
> > format for the brave.
> > 
> >    This lets us get rid of some compat cruft; for example, tdb2 handles
> > multiple opens internally, so the various db_wrap codes wouldn't have
> > to.  We can also add a tdb2 alloc attribute to (finally!) make tdb2 use
> > talloc() for SAMBA.
> > 
> > I'm particularly interested in regressions if we turn this on.  For
> > example, tdb2 functions return the negative error code, not -1: I think
> > I got all the callers, but new ones may appear.
> > 
> > Thoughts?
> > Rusty.
> 
> I'd like a more thought out transition. Distributions build TDB
> standalone and this means it will probably require a so name bump and
> relinking of all users.

Yes, tdb2 is a private library at the moment.  Once it becomes a
standalone library, it will be libtdb with a larger major soname.  At
that point, we're committing to the API.

This is why I'm suggesting we stick with tdb1 compatibility for the
moment: then there's no reason that anyone else needs to upgrade to tdb2
to interact.

This gives us a little more wiggle room if we really want to change
things as we start to use it. 

> Also using an environment variable to change
> format seem sort of dangerous to me. Wouldn't it be better to make it an
> explicit option in the new tdb_open (assuming it is not already).

Sorry, I was unclear.  It's an explicit flag in tdb2 (TDB_VERSION1).
Adding that unless then env var is set is internal to samba's
lib/tdb_compat.

Hope that clarifies!
Rusty.


More information about the samba-technical mailing list