tight loop in tdb_find()

tridge at samba.org tridge at samba.org
Fri May 22 01:38:58 GMT 2009


Hi Volker,

 > There's also bug 5105, awaiting feedback from Tridge.

sorry, I had forgotten that one was there.

Looking at it now makes me think we need to change the strategy for
gencache. Currently it is a database that is frequently written, is
not opened with TDB_CLEAR_IF_FIRST and doesn't use transactions for
writes. 

That is really a recipe for trouble. Any power failure or unexpected
termination of smbd could cause subsequent restarts of smbd to behave
in totally unpredictable ways, including the possibility of returning
incorrect answers to queries. 

The patch you've proposed would mean that smbd would keep limping
along forever with a corrupt gencache.tdb, consuming huge amounts of
CPU. There will be messages in the logs, but I'd guess most sysadmins
would ignore those (especially if Samba were part of an appliance). It
won't prevent incorrect answers coming back from a corrupt tdb though,
and it won't detect and avoid all the possible types of corruption.

I can see a few ways we could fix this properly:

 1) make gencache.tdb use transactions for writes. Whether the
 performance of that is acceptable depends on the ratio of the
 transaction write time (typically about 0.2 seconds) to the cost of
 the cached operation.

 2) make gencache.tdb use TDB_CLEAR_IF_FIRST. Is that acceptable? Do
 we really need to be able to use cached data from previous runs of
 smbd?

 3) Add support for async transaction stores. We could use the forked
 child stuff we've discussed recently to allow for a transaction store
 to gencache.tdb to proceed while the parent continues. 

 4) Use a 2 level cache for gencache.tdb. The first level would use
 TDB_CLEAR_IF_FIRST and the 2nd level would use transactions. We'd
 keep a record in the first level that says how old the oldest record
 in that first level tdb is and how many records are in the first
 level. When those go past a threshold then we would do a single
 transaction to move them into the 2nd level cache. The downside is
 that gencache reads would involve two tdb_fetch() calls, but it would
 mean that the average cost of stores would be fast.

Can you think of any other approaches to fix this?

Are there any other databases in Samba3 that are persistent and don't
use transactions?

Cheers, Tridge


More information about the samba-technical mailing list