[19753] in Kerberos_V5_Development
Re: LMDB KDB module design notes
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Sun Apr 15 16:52:24 2018
MIME-Version: 1.0
In-Reply-To: <be864202-0e62-3b01-c89b-bb2145c687a5@mit.edu>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Sun, 15 Apr 2018 16:51:57 -0400
Message-ID: <CAOASepPYOzr3UC=z7b9Cgi9=usnrx0a6rppERj-paLE8DaCFLA@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, Apr 12, 2018 at 12:34 PM, Greg Hudson <ghudson@mit.edu> wrote:
> On 04/12/2018 11:56 AM, Simo Sorce wrote:
>>> Transactions are per-environment, so if we use one database file and a
>>> write transaction for loads, loads would block the KDC. That's worse
>>> than what we have with DB2.
Could loads be segmented into chunks to avoid blocking the KDC for the
entire operation?
>>> Alternatively we could load into a temporary database file and rename it
>>> into place like we do with DB2. But we would then have to close and
>>> reopen the database between operations like we do with DB2, or somehow
>>> signal processes that have the database open to reopen it after a load
>>> completes.
>>
>> How common are loads ?
>
> That's hard to predict, but for a large database, having the KDC block
> for the lifetime of a load operation seems like a pretty noticeable problem.
>
>> As far as I know LMDB will let you keep reading during a transaction, so
>> the KDC would block only if there are write operations, but won't block
>> in general, right ?
>
> Yes.
>
>> The only write operations are on AS requests, when lockout are enabled
>> and when that triggers a change in the lockout fields. How common is that ?
>
> By default, every successful AS request on a principal requiring preauth
> updates the last_success timestamp. If disable_last_success is set (but
> disable_lockout is not), only failed AS requests would cause a KDC write.
Could you create an opportunistic write queue for these ? This would
unblock the KDC during loads. The cost would be that the
aforementioned writes would not occur until the ends of the loads.
Slightly stale data is probably not a big deal for (at least)
last_success.
>> Would that something that can be mitigated by deferring those writes during
>> transactions ?
>
> I don't see a way in LMDB to check for a write transaction, or begin a
> write transaction without blocking. Queueing those writes to be
> performed later would also add a lot of complexity.
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
