Patch to support Scalable CTDB

Partha Sarathi at
Sun Apr 29 17:29:51 UTC 2018

Hi Ralph,

Thanks, for checking on this.

These are the slide deck contents of 2016 SNIA conference by Volker.

locking.tdb  Scalability

> Locking.tdb is Samba's central store for open file handle information.

* Every file open/close goes through locking.tdb
* One record per inode carries all share modes, leases, etc
* Modern clients \\server\share directory handle open
    * Nonclustered Samba copes with it, although records get large
     * Clustered locking.tdb record becomes "hot", bouncing between nodes
>>>>>>> This particular reason "itched me" :-)
 * For the share root directory, you might cheat
       * Assign per-node fake device number for \
        * No record bouncing, no cross share modes
 * phonebook.exe still a problem
     * Split up locking.tdb per node and global component >>>>> So I
started scratching :-)
* Only store the strictest share mode in ctdb
   * Keep individual share modes local per node.


I hope my understanding is correct and  I started trying to solve the above
problem, if not please correct me and shed some light  and please
suggest/provided an alternate solution to scale CTDB in the large node


On Sat, Apr 28, 2018 at 7:33 AM, Ralph Böhme <slow at> wrote:

> Hi Partha,
> On Thu, Apr 26, 2018 at 05:14:54PM -0700, Partha Sarathi via
> samba-technical wrote:
> > We have a requirement to support a large cluster i.e scaling from 20
> nodes
> > to 50 nodes cluster and the current CTDB design may not support the
> linear
> > scaling of nodes in the cluster as the replication of all lock
> > related tdbs and tdb traversing for every record may slow down the
> > performance.
> hm, which itch are you actually trying to scratch here?
> I guess there are two scalability problems in the context of volatile dbs
> (eg
> locking.tdb) in ctdb: record contention and vacuuming. Traverses are
> normally
> not an issue as smbd doesn't request traverses of volatile dbs in
> production. Am
> I missing something? Is vacuuming really a problem? Amitay?
> -slow
> --
> Ralph Boehme, Samba Team
> Samba Developer, SerNet GmbH
> GPG Key Fingerprint:           FAE2 C608 8A24 2520 51C5
>                                59E4 AA1E 9B71 2639 9E46

Thanks & Regards

More information about the samba-technical mailing list