Locking database cleanup?

[tridge at samba.org]

Jeremy,

 > That's probably not the locking or open mode database though, which
 > is what was being complained about.

yep, for the temporary databases transactions it isn't worth the
fsync() cost. In Samba4 we cope with this by having a separate
directory for the temporary databases, and that directory is deleted
and re-created on smbd restart. That avoids the TDB_CLEAR_IF_FIRST
problems.

The interesting situation is someone killing just one of the smbd
processes while in a tdb write, and the other smbd processes trying to
continue with a potentially corrupt db. I guess we could cope with
this by using transactions, but with TDB_NOSYNC, which gives us the
atomicity needed without having the robustness against system
crash. In case of system crash all smbd processes will restart, so the
temporary directory method copes with that.

When you use TDB_NOSYNC transactions cost very little (although they
do reduce the parallelism, which might hurt enough to matter for the
locking db).

The transaction code would need some modifications to be used like
this. Right now it only checks the flag that indicates that
transaction recovery is needed at open time. To cope with the "kill
one smbd" scenario we'd need to check if recovery is needed on every
operation. It's a very fast check (reading 1 word) so hopefully that
wouldn't be too much of a performance hit.

 > I think transactional tdb is an excellent idea for the account databases
 > though.

yep, and some others, like the print drivers db and the winbind user
map db. Basically all of the long lived databases should be
transactional, with TDB_NOSYNC not set.

Cheers, Tridge