apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <li...@holsman.net>
Subject Re: apr-util/dbm/sdbm page sizes
Date Sat, 20 Sep 2003 04:20:44 GMT
William A. Rowe, Jr. wrote:
> As a few here already know, we used the 'Standard' page size for our
> apr-util SDBM implementation.  This assures that you can modify our
> sdbm files from perl and other tools.
> However, it's pretty clear that 1024 just doesn't cut it when it comes
> to huge objects from ssl caching and other sorts of large blobs.  The
> modssl project (1.3) had tweaked sdbm to take larger page sizes, but
> this leads to an inflexible implementation (another fixed page size, but
> incompatible with other implementations.)
> I'd like to see apr-util support alternate sized dbm pages, but without
> making fixed assumptions about those sizes (other than this - the 
> structure uses short's for offsets, so the page size does have a cap.)
> The attached patch allows the SDBM to be of any arbitrary data and
> directory page sizes.  However, I've not hacked in any method of
> declaring what those sizes should be (they are the 'standard' defaults
> at the moment.)
> What do folks believe is the most rational approach to expanding support 
> to create an sdbm with alternate page sizes?  And how best can we embed 
> that info into the sdbm so that later accesses to the file use the correct
> page size?  My current thought is to embed a NULL-key record at the head
> of the file, with a specific known value element containing some identifier
> string such as "APR-SDBM" followed by two ints, the page and data len.
> If that record is missing (or created with default sizes), the file is treated 
> as a standard sdbm with 1024/4096 sized pages.
> Other thoughts, suggestions or observations?
> Bill
+1 SDBM as currently implemented is next to useless on a large number of 
records either.
you'll need to modify apr_dbm_open call so it can pass a page size (so 
you can create the sucker)

I'm still curious on why people just don't use berkeley DB (except for 
licencing issues I guess)

are there any other BSD-style DBM formats we could use?

View raw message