Principal DB Size
jhutz at cmu.edu
Fri Jun 18 16:01:16 EDT 2004
On Friday, June 18, 2004 15:46:16 -0400 Ken Raeburn <raeburn at mit.edu> wrote:
> On Jun 17, 2004, at 20:26, Brian Sathianathan wrote:
>> I tried pointing the kerberos database to a different db ( Berkely Db
>> 4.2) during the ./configure stage didn't help I still hit that limit.
>> I also went through the database related source code functions
>> (krb5_db2_db_put_principal.krb5_db2_db_get_principal ) looking for
>> some integer that might overflow( because 4.2G sounded like an integer
>> limit) didn't find any type limitation there . The type limitations
>> that you mentioned are they in the database code or the interface code
>> , if they are in the database code it self , Can you give me some
>> functions or module names you suspect the limitation might be in
> My first guess was "anything computing an offset to pass to lseek". I
> checked our db2 code and found a couple places where nonzero offsets were
> being computed, and found it was multiplying pagesize*pagenum without
> checking for overflow. I don't know if that's actually the problem (I'll
> have to free up a few gigabytes to run the tests), and the new db code,
> if it's got large file support, really should take care of such issues.
> Without such a check, corruption seems likely; with a check, it ought to
> result in an error when storing the new record, but no corruption of the
> on-disk database. With large file support, like I said, it just
> shouldn't be a problem, but apparently that's not the case...
If the values you are multiplying do not have 64-bit type, then the result
will not have 64-bit type, even if you are passing it to a function which
takes a 64-bit parameter -- the type of an expression does not depend on
what you are doing with its value. Casting pagesize to the type of the
argument (loff_t or some such?) may make the problem go away.
More information about the krbdev