Date: Wed, 28 Aug 2013 18:48:43 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: RE: [krbdev.mit.edu #7695] krb5-1.11.3/1.10.6 - full resync may fail and still result in ulog being updated
In-Reply-To: 
To: 'Richard Basch' <basch@alum.mit.edu>, rt-comment@krbdev.mit.edu
Message-ID: <07a801cea440$bf5da290$3e18e7b0$@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Language: en-us
Content-Transfer-Encoding: 7BIT
Thread-Index: Ac6kOyDDDvoyFAFXRWWfXC0DxqpI8gAA+IyAAABtlTA=
References: <rt-7695@krbdev.mit.edu> <rt-7695-38960.1.05981958099434@krbdev.mit.edu>
RT-Send-Cc: 
Content-Length: 1711

My concern was within restore_dump()... it calls krb5_db_put_principal()
which in turn calls ulog_lock for each record (this was a major performance
hit especially with a database with about a half-million principals). Under
Kerberos 1.10, I found it only took 2-3 minutes to load the database (and
another 2-3 to send it over the wire), but I was seeing inordinately long
load times which I could trace back to the ulog_lock/unlock for every
record. I will have to review the master branch carefully, but if that code
also exists in the master branch, see how long it takes to do a dump/restore
for a database with about 500,000 principals (and compare it with the time
it took under Kerberos 1.10.x).

And I agree with you that I might have introduced the performance issue with
my first patch (when I moved the iproprole setting, which is why I set it to
IPROP_NULL as it was in the original state before I patched it).

I am confused how you say the third patch is broken, as by this point, the
ulog is mapped and I am setting the ulog at the end of the restore. During
the restore, you do not want to be touching the ulog at all (e.g.
IPROP_NULL) because the database being restored is "on the side". Once it is
promoted, one might argue the first thing should be to set it to
IPROP_SLAVE, then set the information, but that is not what was in the code
originally either.

The goal should be not to allow any ulog processing or locking during the
restore (which is to a temp db anyway), and then set the ulog state after
the restore.

I will play around with the master branch (what I supplied was based on the
1.11 branch and empirical testing, but the two branches have deviated enough
at this point).