Hierarchical iprop project review

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Hierarchical iprop project review

Greg Hudson
Some time ago, Richard Basch submitted code to support a hierarchical
arrangement of slaves for incremental propagation--an intermediate slave
can run "kadmind -proponly" to serve incremental updates to other
slaves, and a downstream slave can run "kpropd -A upstreamslave" to
point at an intermediate slave instead of the master.  This feature can
be useful in environments where either performance or network topology
makes it undesirable to serve incremental updates to every slave from a
single master.

I have finished reworking the code and have written up a detailed
project page summarizing the design changes.  The project page is at:

    http://k5wiki.kerberos.org/wiki/Projects/Hierarchical_iprop

It takes a while to wrap one's head around the ulog design, but if
anyone is sufficiently interested, comments are welcome.

This project does not include the automatic notification work that
Richard did more recently; integrating that will come later.  The
project page also notes some ancillary performance improvement
opportunities.

The code is currently in the hieriprop branch on my github fork:

    https://github.com/greghudson/krb5/commits/ipropbug

It rests on top of two other branches, ipropbug and ipropcleanup, which
are not specifically related to hierarchical iprop.  In total there are
17 commits.  I expect to push these branches over the next couple of
weeks.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Hierarchical iprop project review

Greg Hudson
On 01/30/2014 01:28 PM, Greg Hudson wrote:
> I have finished reworking the code and have written up a detailed
> project page summarizing the design changes.

There is a potential problem with deadlock in my patch series, which
raises a design question about how we should do locking in iprop support.

Right now there is a lock on the ulog file, which is usually obtained
implicitly inside the kdb_log.c functions.  There is also the database
lock in the DB2 back end (two of them, actually, but ignore that for
now), which can be obtained explicitly with krb5_db_lock or implicitly
by performing a KDB read or write operation.  Several operations need to
serialize both resources at once, and if they lock in different orders,
deadlock can result.

Nico proposes ditching the ulog lock and just locking the database to
serialize access to the ulog.  With only one lock, there can be no
deadlock.  This approach would unnecessarily serialize ulog operations
against KDB reads and unlogged KDB updates, but that's a small cost.
Another consideration is that the LDAP KDB module does not support
locking; this is not necessarily a big deal since iprop already doesn't
work with an LDAP master, but we would be further entrenching that
restriction in the iprop design.

The less aggressive approach is to define an order (such as "always lock
ulog before DB"), document this order in appropriately placed comments,
and make sure all of the aforementioned operations obey the order.
Right now kdb5_util dump is the outlier, so it would have to expicitly
lock the ulog before locking the DB.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev