v6.50 Odd Header Database Compaction Dialog

[zforgetaboutit]

Just installed 6.50.

Compaction #1: Let's say there are 1+n groups in a GOG. During a GOG compaction process when the focus moves to group #2 and before the whole process completes, the right-side size for the preceding group's interim final size is sometimes bigger than its original size. When all the groups have been 'compacted' some are bigger, some smaller.

For a particular GOG example this same dialog (screenshot saved) shows a final reduction in size for 7 of 8 groups, and an increase for 1 group with an overall 'space recovered' of 0 KB. One of the groups space usage went from 3.23 GB -> 3.43 GB .

Compaction #2: same GOG. It finished but shows the same numbers as compaction #1.

Compaction #3: restarted Newsbin - same GOG. Now it claims 900+ MB space recovered.

Compaction #4: different GOG - alt.binaries.multimedia - purge to display age (7 days) - post-compaction it claims the current size = 3 GB. I can't believe this is 7 days of headers.

Compaction #5: restarted Newsbin - alt.binaries.multimedia - purge to display age (7 days) - ran for 1-2 seconds - post-compaction it still claims the current size = 3 GB.

I'm perceiving the displayed metrics of pre- and post- compaction activities are somewhat wrong. It looks big but runs small.

As I write this, the GOGs from compaction #1/#2 acts GB big when copying spool files to NAS. So for some reason they actually weren't compacted to 7 days.

Comments?

[Quade]

Compaction doesn't purge. It just compacts. If you want to purge, you set the storage age, then update the group. When the update completes, the purge will happen.

As for the sizing thing, I'll have to check it out. It's possible for compaction without deletion to result in a bigger DB. Sometimes the Db adds new indexes that can flesh the size out.

[zforgetaboutit]

I hear you, but I believe I originally mentioned purging followed by compaction in #4/#5.

Retrying after a newsbin restart. Purge to 7 days (as before it ran for about 1 second). The compaction dialog shows 4.3 GB used but the pre- compaction sizes only add up to < 2 GB. Math seems wrong.

The a.b.multimedia spool folder really is 3 GB in size, after a purge-to-7-days.

Having written this I admit I've been doing a purge-to-display-age. It's in the 'post storage sub-menu' Maybe this doesn't quite work?

Compaction #6 - I'm now retrying with the purge-to-storage-age (7 days)/compaction steps. Hmm... the choices for compaction are 'purge to display age', 'use download age' - I don't see 'storage age' as you mentioned.

I know my experience with 6.50 is very new (today) but am I perceiving things incorrectly?

[dexter]

Storage Age is set under Options/Setup. Quade is saying that Newsbin automatically purges to the storage age whenever you download headers, you don't explicitly tell it to purge to Storage Age. So if you set the Storage age to 30 and download 60 days of headers, anything older than 30 days will get purged from disk.

[zforgetaboutit]

Thanks for the reply.

That part I knew about. But what I'm asking about specifically is the 'post storage -> purge to display age' feature seen when right clicking on a group or GOG in the 'Groups List' tab..

My expectation, right or wrong, is the task above should mark as deleted all records ~older than 'display date' and then compact the chosen groups in one step.

If this is wrong then what is it supposed to do?

[dexter]

That option will delete posts from the header database older than the Display Age setting but it will not automatically perform a compaction of the database. So after the deletion, the actual size of the database file will not be reduced unless you manually choose Compact Database afterwards.

[zforgetaboutit]

Then we've come full circle. ^-^

1. I just confirmed 'display age' = 7 days.

2. I right-clicked on a GoG and chose 'post storage' -> 'purge to display age'. A progress bar existed for about a second. I now expect the non-compacted database to logically contain 7 days of headers - maybe a couple hundred MB?

3. I then chose 'post storage' -> 'compact database'. I expect the database to shrink to a mere week's worth of logical & physical records. The results are still 3 GB before and 3 GB after. No compaction seems to have happened.

I think something's lost in translation between us. I'm hopeful everything will turn out OK eventually.

Maybe you could please give me a step-by-step recipe where my 3 GB of storage used for a single group can be physically shrunk to a week's worth of headers, far less than 3 GB? I promise to follow the steps religiously. If it works then I should be able to dupe it for the the other GoGs I want to trim.

[dexter]

It is possible that it is broken. I'll give it a try myself when I get a chance.