New configuration backends for Samba 3 SoC project

simo idra at
Wed May 31 12:50:33 GMT 2006

On Wed, 2006-05-31 at 15:43 +0530, Chetan S wrote:
> On 5/28/06, simo <idra at> wrote:
> > On Sat, 2006-05-27 at 15:12 -0500, Gerald (Jerry) Carter wrote:
> > > Most of the lp_XXX() functions can be wrapped around
> > > a simple query call.  The main hurdles are smb.conf
> > > variables and the include parameter.
> >
> > A careful analysis on lp_XXX() calls need to be made.
> > In some places we call lp_XXX() quite much as we knew they were just
> > references to in memory strings.
> > We can't move to querying a db for each retrieval without suffering
> > major performance issues.
> >
> > We may end up requiring a cache system to not destroy performances.
> > (Think of how much lp_workgroup() is used (more than 200)).
> >
> Just out of curiosity - is there some kind of writeback strategy
> employed in ldb if the variables are stored in memory ?
> I had this question from the idea that performance issues can be
> pretty much be dealt with if part / entire dbs are shifted into memory
> with periodic writeback. This should sound more like caching in
> implementation.
> The decision to make a variable / parameter memory based+writeback,
> can be configurable parameter again :)

Well, when ldb uses a tdb as backend we really have everything in memory
as we use mmap to open tdb files. But even when the files are in memory
searching through them cost too much in some code paths.

I think we can keep using the prefilled lp_XXX() options in some cases
(things the never change in the current session), and leave the searches
for the code paths that are not so speed sensitive.


Simo Sorce
Samba Team GPL Compliance Officer
email: idra at

More information about the samba-technical mailing list