Newsgroups: comp.os.msdos.apps,comp.bbs.waffle
Subject: Re: A Poor Stacker application
From: dogbowl@dogbox.acme.gen.nz (dogbowl)
Date: Wed, 19 Aug 92 15:54:14 NZT
Organization: The Dawghaus BBS
Keywords: stacker
Summary: sdefrag /r won't work with more than 16000 files

darkstar@pecan.cns.udel.edu (The Janitor Of Anarchy) writes:

> In article <ygumPB5w165w@dogbox.acme.gen.nz> dogbowl@dogbox.acme.gen.nz (dogb
> >phil@miracle.com (Phil Hill) writes:
> >
> >> will give you 30MB of free space...
> >> 
> >> The final result: 105MB of news on 22MB of disk.  I'd say it's worth it!
> >> -------------------------------------------------------------------------
> >
> >Don't bank on it. Stacker can tell *BIG* lies about compression ratios.
> >I thought that I was doing quite well when scheck reported 400Mb being 
> >compressed into 86Mb of actual space, but when I added up the file sizes 
> >using Xtree, I found that it was actually 134Mb.  This was happening on a 
> >213Mb partition.
> >Now that I know that the reports are unreliable I keep a close eye on 
> >what it says. 
> >
> >Ideally the cluster size needs to be around 256 or 512 bytes.
> >I'd prefer to keep using Stacker, as I went and bought the coprocessor 
> >card to speed things up. Anybody got ideas on tweaks??
> >
> >
> Well, Stacker isn't really to blame, you are *8).  The problem is that
> you're allowing Stacker to lie to you.  What you need to do is run 
> SDEFRAG with the /R and /G options.  The /r option tells Stacker to 
> recompress the data, and the /g option tells Stacker to change the size
> of the Stacker drive.  It doesn't physically change the drive's size, 
> but what it does is it changes the drive ratio.  Also, what it does is
> change it to the actual ratio that scheck reports, not the ration 
> everyone hopes they get!!!.  In other words, if you think you're getting
> 2.0:1.0 but scheck reports 1.3:1.0, then you need to change the drive
> ratio, so you actually know how much space you're getting...
> 
> Now try that out, and see how close Stacker and XTree are!
> 

I know about these features.
Problems....

1: Sdefrag won't work with more than 16000 files on the disk.
   for that matter, Xtree won't either. I had to log each major directory 
   tree individually and add the file sizes by hand. Also I can't get a 
   slack space report

2: While Stacker's cluster sizes are 4k, the average size of files in my  
   Usenet partiton is 1.5k. That's why I want to fiddle the cluster size

3: running Sdefrag takes approximately 9 HOURS on my machine at the 
   moment. On a BBS it's hard to justify taking it down for this amount   
   of time more than once a month.

4: running sdefrag /g tells me that I am achieving 4.5:1 compression 
   ratio, but then only allows me to alter the ratio to 4.1:1, which  
   is what I'm running it at anyway.

So what I want ( ideally ) is some way of allowing stacker to have 
smaller clusters and sdefrag /r to work with massive numbers of files. 
( I wouldn't mind if it had to use virtual memory on another disk if it 
  had to. there's 100Mb in anotherdrive available, plus 4megs in XMS )

Also, it would be nice if XTG could handle more than 13,450 files.

Bear in mind that I want to expand my newsfeed, and so may end up having  
50,000 messages (or more) on the system.

Any suggestions or help are more than welcome.

Alan Brown.

dogbowl at The Dawghaus BBS  ( +64 6 357-9245 )


Xref: sparky comp.os.msdos.apps:4331 comp.sys.ibm.pc.misc:11499 comp.binaries.ibm.pc.d:3296