INN 2.3x and hardware
rmtodd at servalan.servalan.com
Fri Sep 22 23:16:50 UTC 2000
In servalan.mailinglist.inn-workers you write:
>Russ Allbery <rra at stanford.edu> wrote:
>>> This is very weird. Which part of INN requires file locking?
>>> I don't think the spool needs it, to get more performance you should
>>> try mounting it again without locking.
>> I believe all of tradindexed, buffindexed, and ovdb (by way of
>> Berkeley DB) use fcntl file locking.
>Ok, let's scrape all the information together and try to get
>a picture. :-) That's what I have:
>* mmap: All overview methods use mmap (regarding one of Heath'
> older mails, <200007131941.OAA00745 at darkside.norand.com>).
>* Locking: All overview methods use fcntl file locking.
>* Heath also mentioned http://www.sleepycat.com/docs/ref/env/remote.html
> for ovdb (-> Berkeley DB and remote file systems).
>What about the rest and mmap / locking? Spool (as I mentioned,
>we'd like to use timecaf), active, history etc.?
Active and history both use mmap. (History could probably be made to not
use mmap with minimal hacking to the dbzsetoption calls in innd, but since
you still need to be able to mmap() active, this probably won't be of
Timecaf uses whatever locking mechanism is
in the lock_file() library function, probably fcntl(). Whether or not it
uses mmap() is controlled by the 'articlemmap' inn.conf option. Tradspool
does no locking, and obeys the articlemmap option same as timecaf (probably
because I swiped the code from there :-). Timehash is the same way.
CNFS doesn't do locking, and always wants to use mmap.
More information about the inn-workers