Newsgroups: news.software.b
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: CNews building up files in "in.coming"
Message-ID: <1989Oct25.214735.11581@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Oct22.192159.4827@acd4.UUCP> <1989Oct23.023759.17067@utzoo.uucp> <1989Oct25.023352.8840@twwells.com>
Date: Wed, 25 Oct 89 21:47:35 GMT

In article <1989Oct25.023352.8840@twwells.com> bill@twwells.com (T. William Wells) writes:
>Could you either make this based on the file sizes, or provide an
>option or configuration parameter to make it delete after each
>batch? Perhaps you could make that 50 a configuration parameter?

Exactly what should the algorithm be for deciding how to make the choice?
The current code does it based on whether space is tight or not; this
seemed the only reasonable rule to me.  If there is lots of space, better
to optimize for time.  If space is tight, better pay more attention to
that.  How else?  I don't understand the circumstances in which the
current code is as ill-behaved as you imply; can you elaborate?

(If it's because the space margins in "spacefor" are set to zero or some
very small number, your warranty is void. :-))

>Now that I think about it, I have a feeling that there are
>several assumptions in C news that are invalid when batch sizes
>are typically very large. Perhaps you might want to think in terms
>of a configuration options for these kinds of systems.

Compressed batches of 200-300K are common here; we haven't seen any
problem with them.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
