Text 22, 69 rader
Skriven 2004-12-14 12:09:06 av Roy J. Tellason (1:270/615.0)
     Kommentar till text 11 av Mike Tripp (1:382/61)
Ärende: file size issues?
=========================
Mike Tripp wrote in a message to Roy J. Tellason:

 MT> Hello Roy!

 MT> 02 Aug 04 04:07, Roy J. Tellason wrote to Mike Tripp:

 MT>> The new version was only growing to swallow the new messages
 MT>> being appended, so there's no reason for them to be occupying
 MT>> more than the actual number of bytes required to do so.

 RT> Yup.  And the way things looked it wasn't ever gonna get any smaller.
 RT> I'm looking at something like 38M currently on that drive,  not so
 RT> much that I need to worry about an 8M file eating too much space but
 RT> still...

 MT> I was referring to your new replacement files here, not the
 MT> original hosed version.  If you don't assign it any purge
 MT> paramaters either, then there's no reason for SQPACK to ever shrink
 MT> the file, and it should head straight back for 8mb or however far
 MT> it grows until it a data integrity issue stops one utility or
 MT> another from being able to interact with it correctly any more.

A data integrity issue?  Hmm.

 MT> If you want to keep areas uncapped, it might help to do a monthly
 MT> SQREIDX or SQFIX event to catch little issues before they become
 MT> big/fatal issues.

I never thought about sqreidx,  missed that one completely.  Sure enough, 
there it is,  right in my squish directory where it should be!

Actually what I plan on doing is archiving the stuff I want to keep about once
a month (keeping it in month-sized chunks) and then deleting those from the
active message base.  What I put off for *way* too long with this particular
area,  since the archives I did end up creating go all the way back to last
November.

 RT> Makes sense.  This also explains some why TimED's undelete
 RT> function seems to grab *all* deleted messages,  I guess that was
 RT> just simpler to code,  or something.

 MT> Yep...and probably has the same pitfoils as UNDELETE in DOS. 
 MT> "Deleted" data is overwritten by new data arriving...so some
 MT> deleted msgs are unrecoverable. TimEd is probably just grabbing all
 MT> of the puzzle pieces it can find to start with, figuring out which
 MT> fit together, and then throwing away the few leftovers that don't
 MT> seem to fit anywhere when done.

Or something.  I don't use it that often to be able to guess.

 RT> There are only a few areas like that here,  most are set for
 RT> specified time frames,  typically 60 days.

 MT> SQUISH and SQPACK work together to maintain the quantity limit.

Yeah,  which is why I use it seldom,  since it slows down message tossing.

 MT> SQPACK alone does the limit by days.  SQPACK should =always= show
 MT> some shrinkage on each daily run for areas with a days limit,
 MT> unless the area is newer than the limit or the area has days
 MT> without mail.

Sounds right to me!

I just wonder what the problem was.  Oh well.  I won't likely be letting any
area get that big again so I probably won't run into the problem again...

--- 
 * Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)