Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Mar 97 12:37:36 CST
From:      Joe Greco <jgreco@solaria.sol.net>
To:        terry@lambert.org (Terry Lambert)
Cc:        terry@lambert.org, scrappy@hub.org, marc@bowtie.nl, neal@pernet.net, hackers@freebsd.org
Subject:   Re: freebsd as a news server?
Message-ID:  <199703111837.MAA29432@solaria.sol.net>
In-Reply-To: <199703111809.LAA25711@phaeton.artisoft.com> from "Terry Lambert" at Mar 11, 97 11:09:06 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > Terry, what ARE you babbling about?
> > 
> > We're discussing INN here, not some hypothetical news system.
> > 
> > INN is particularly good at recovering from a crash, although there are
> > a few things on my wish list, but worrying about some mythical "index file"
> > is not among them.
> 
> I mean "index" in the database sense of the word, not "index" as in a
> file name.
> 
> Any time you have a list that isn't stored as directory data, you have
> an index.

Terry, what ARE you babbling about?

A list that is stored as directory data certainly IS an index, and INN
really does not use anything much more complicated than the FS structure,
flat files, and a big hash table _anywhere_ in the code.  If you wish to
insist on calling _those_ indexes and databases, fine, but your original 
babble still makes no sense even in that context.

What little chance there is for desynchronization is generally worked
around in various manners.  A great example is the news overview
"database"...  if it is missing, broken, or doesn't contain the
information, the data is generated on the fly.

In the commonly distributed version of INN, the current spool IS the final
authority as far as which articles exist and which don't.  If you choose
to crash the system, clri a bunch of articles and then fsck the file 
system, INN will take the spool's current state as being authoritative.
If you wipe out the overview caches, it will generate that data from
the actual article files.  Neither case is a problem.

That's why I don't really CARE if I lose bunches of files when I mount
my disks -o async.  It is a system that is relatively impervious to
various sorts of {Terry-imagined,real} damage,

If you really want, I could take you on a nice personal tour of all the
code, because I've spent the last three months buried in it, doing various
performance enhancements.

Actually I'm quite tired of staring at it, because I keep wishing that it
was more sophisticated.  :-)

... JG



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111837.MAA29432>