Subj : file size issues?
To : Mike Tripp
From : Roy J. Tellason
Date : Tue Dec 14 2004 12:09 pm
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)
