Never say never! Okay, sometimes say never. But don't always say never. Are
we not all temporal transitory beings who strut a little and... on
nevermind. What i wanted to say reply to Albert:
>The way I see it, the newsbase adopts some pessimistic release
>algorithm. When an article is deleted, the space is not released
>back immediately; rather, Yarn will see for a few days if this space
The news.dat truncates itself whenever "available" space occures
at it's end. So what you are waiting for is your free space to
occur on the end of the file... it happens eventually.
For example with with Yngvar's example:
>Meaning that when some spammer posts a five-megabyte binary, I can't
>reclaim that space on my hard disk afterwards without deleting my entire
>news base.
When the 5 megabyte article is expired and made "available" space... that's
al lot of space. New articles will be imported into that space, and the
space after that large hole probably won't be touched and will expire at
the end of the file, then it will be truncated (eventually).
This is my theory, loosely based on the few facts I know. I"m still not
100% certain how Yarn replaces the 'available' blocks. For example if you
run NNIGN you see there is slack space at the end of some articles. So yarn
must have a threshhold that doesn't mark available very small blocks. Let
us in our theorising consider my news.dat file as it currently exists (gee
i feel like i'm trying to decypher newly discovered language or something.
Chin must be ammused by our floundering and trying to explain how his
program works <G>):
News spool size is 11,929,434 bytes (96/05/13 0:37)
+---------------------------------------------------------------------------+
| Block Type | Bytes Blocks % | Average Biggest Tiniest |
|------------+--------------------------------+-----------------------------|
| In Use | 8,889,857 3,823 74.8% | 2,325 80,728 192 |
| [Articles] | 8,493,283 3,823 71.5% | 2,221 80,728 192 |
| [Slack] | 396,574 968 3.3% | 103 1,022 1 |
| Available | 2,990,321 280 25.2% | 10,679 69,409 360 |
+---------------------------------------------------------------------------+
Notice the biggest chunk of what i've called 'slack' space is 1,022 bytes.
Yet the smallest block of "available" space is 360 bytes (which one would
think would be too small for anything, except I can see there my smallest
article is only 192 bytes, so THEORETICALLY something could fit in there
<-; no matter how unlikely it occuring)!
So what i wonder from this is how there can be a condition that will leave
a tiny avilable block of 360 bytes, and yet there are "slack" at the end
of other articles as big as a k. (though not many since the average is only
103 bytes). I guess perhaps it has some to do with luck and articles
matching close to the size of the available block they are replacing. But
there has to be some threshold where chin decides to not make the extra
space "available" but just leave it "slack" on the end of an article.
Of course none of this matters too much, as it's a small value whatever it
is (-: I just like talking about it. <-;
Now what was the point we were getting at?
Oh yes, as John replied, and i shriek as usual:
>As has been pointed out before, using REBUILD -S shrinks
>news.dat down to unexpired news only.
Warning! WARNING! this resets all your import dates so they will not
expire until the full expire time is up again. So unless you use always
expire -r and don't care about expirey times, or your spool is corrupt,
don't do it!
--
.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.
Tim Muddleton =-= not all who wander are lost =-= as544@torfree.net
-=-= check into the New International Translation of the Bible =-=-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yarn/2 Bells & Whistles Page: http://www.io.org/~tm/bells2.html