summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorVolker Lendecke <vl@samba.org>2019-05-20 16:01:03 +0200
committerJeremy Allison <jra@samba.org>2019-05-24 00:42:17 +0000
commite7424897a1272490b78c08f78ce7b260eb014f20 (patch)
tree28b9de7417e81d6f3e94bdf67e1845e47a01ff7e /include
parent78a4639b2d06cc69788861618d2e91945e142d2b (diff)
downloadsamba-e7424897a1272490b78c08f78ce7b260eb014f20.tar.gz
ctdb: Make TDB_SEQNUM work synchronously with ctdb
Old war story completely from memory, I could not find the commit that introduced TDB_SEQNUM so far...: Back in the days when ctdb was initially developed, TDB_SEQNUM's only user was the notify.tdb that held one huge record for all notify records. With that use case in mind it made perfect sense to keep the SEQNUM stable locally, sacrificing precision. By now notify.tdb is long gone, an the only user of TDB_SEQNUM right now is brlock.tdb, which contains special case code for the imprecise ctdb implementation of TDB_SEQNUM. With this commit, that special code can go: The TDB_SEQNUM will also increment when just the DMASTER header field changes, indicating to smbd that someone else might have changed the record. This will of course increase the SEQNUM frequency, but it should not increase the load on ctdb: If you look at the brlock.c workaround, it just does not do the caching that is possible with precise TDB_SEQNUMs working. How did I get here? I want to move brl_num_read_oplocks() from brlock.tdb into locking.tdb, and for that I need precise TDB_SEQNUMs for locking.tdb. Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Jeremy Allison <jra@samba.org> Autobuild-User(master): Jeremy Allison <jra@samba.org> Autobuild-Date(master): Fri May 24 00:42:17 UTC 2019 on sn-devel-184
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions