dbzinit error ...

Richard Michael Todd rmtodd at mailhost.ecn.ou.edu
Thu Nov 4 18:03:20 UTC 1999


In message <yl7ljz6m6k.fsf at windlord.stanford.edu>you write:
>The Hermit Hacker <scrappy at hub.org> writes:
>
>> Ummmm...all and well, but this is a FreeBSD 3.3-STABLE machine I've been
>> hit with this on, or is this an INN flag?
>
>INN doesn't currently support building with large file support on any
>platform other than Solaris that I know of, since it requires getconf
>which appears to be a Solarisism.  I intend to fix that at some point, but
>I was having a really hard time finding any information at all on how to
>build with large file support on anything other than Solaris.

Large file support *should* work OK on FreeBSD or any of the other BSDs as
is, since by default on *BSD off_t is a 64-bit type, so you don't need any
of those mickey-mouse defines that other platforms need.  Admittedly I 
haven't tested this (my history file is only O(250M), and I have lots of
little (300M) CNFS files, because in the past I've found it useful to be able
to change the amount allocated to CNFS by just adding/deleting 
cycbuffs.)

I can think of one thing that may cause problems with big history files. 
Tagged-hash mode only stores 4-byte offsets, even on systems where off_t
is 64 bits.  This was a deliberate design decision, on the grounds that
tagged hash is used by people who are short on memory, and having each
entry in the DBZ table be 8 bytes instead of 4 would be bad, and presumably
anyone who can afford enough disks to require a 2G+ history file can also 
afford enough RAM to avoid tagged-hash.  If for some reason someone wants to
do tagged-hash with a large history file, they can always change the #define
of of_t in lib/dbz.c.


More information about the inn-workers mailing list