Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site oliveb.UUCP
Path: utzoo!linus!decvax!decwrl!Glacier!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry Aguirre)
Newsgroups: net.news
Subject: Re: Quantitative Gloom and Doom
Message-ID: <602@oliveb.UUCP>
Date: Fri, 20-Sep-85 17:25:29 EDT
Article-I.D.: oliveb.602
Posted: Fri Sep 20 17:25:29 1985
Date-Received: Sun, 22-Sep-85 18:47:18 EDT
References: <10277@ucbvax.ARPA>
Organization: Olivetti ATC; Cupertino, Ca
Lines: 52

> Disk Space Usage Summary in /usr/spool/news
> on ucbvax by newsgroup (1024 byte/blocks):
> 
> International Newsgroups:
> 38939	net
> 1575	mod
> 791	fa
> 193	control
> 13	junk
> -----
> 41511
> 	Erik E. Fair	ucbvax!fair	fair@ucbarpa.BERKELEY.EDU

Be carefull of how you make the disk usage measurements.  The "du"
program lies.  I have had it report greater disk usage than the size of
the disk.  There are two sources of errors, "sparse" files and links.

If a file has large areas that were seeked over but never written then
those blocks that would be zero are not allocated but are marked in a
way that later reads can recognize.  The read then simulates the reading
of a block of zeros.  An example of this is the DBM history database
used by news.  Du calculates blocks by dividing the file size (logical)
by the size of the blocks, not always accurate!

The second source of error, which is more relevent here, is the counting
of links.  The storage of news makes use of links to cross post an
article to more than one news group.  An article may appear in both
net.flame and net.sources but only one copy is stored.  The du program
will count each link seperatly.  This usually doubles du's estimate of
usage though the exact ammount depends on the quantity and size of cross
postings.

Both these problems seem to have been fixed in the 4.2BSD version so
whether they affect you depends on what version of Unix you run.  The
link problem can still bite you if you manually add the sizes.

My news directory runs about 13Mb with a 2 week expiration so your size
seems a little high.  Either you receive lots of articles that I don't,
you are getting lots of duplicate articles, or your expire is not deleting
every thing it should.  For 4 weeks you should have under 26Mb, not 41Mb.

The current news history code is a crock and has many loopholes that
allow an article to be received without being entered into the database.
This means that they don't get deleted and that duplicates can be
received.  I had this bite me while testing out a batched version of the
ihave/sendme protocol.  The target system requested several thousand
articles that were not in it's history.  They were, however, already in
the news directory.  Also, unless I regularly (weekly) run an expire -r
then unexpired articles gradually accumulate.

					Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix|olhqma}!oliveb!jerry


Brought to you by Super Global Mega Corp .com