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.
e7424897a12 ctdb: Make TDB_SEQNUM work synchronously with ctdb
ctdb/common/ctdb_ltdb.c | 19 -------------------
ctdb/server/ctdb_ltdb_server.c | 20 --------------------
2 files changed, 39 deletions(-)