tight loop in tdb_find()
tridge at samba.org
tridge at samba.org
Fri May 22 01:38:58 GMT 2009
> 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
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
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
More information about the samba-technical