🚀 go-pugleaf

In a previous article, kris@microware.com (Kris Hoffmeyer) says:

>In article <1992Sep10.165416.14551@rei.com> fox@rei.com (Fuzzy Fox) writes:
>>
>>A quick note on Norton's FS -- It will tell you that there is unused
>>slack space on the Stacker drive, but what Norton doesn't realize is
>>that Stacker actually re-uses this slack space during its compression.
>>So any figures you see on slack space are reported by unaware software.
>>Stacker drives have very little slack space at all.
>
>I don't understand how stacker does not have slack space...
>Stacker does allow you to set the file block size, but it installs
>at 8K blocks, right?  So if a file or it's last block is less than
>8K, the rest is "slack", isn't it?   I could see Norton's FS getting
>confused and being inaccurate in reporting slack space, but how does
>Stacker fix the "slack" issue...?

Stacker internally allocates in 512-byte clusters.  So, for an 8192-byte
cluster, compression can be 1.0:1 (Takes at least 15x512+1 bytes to
store) to 16.0:1 (Takes <=512 bytes to store).

Incidentally, it appears that Stacker (And possibly superstor) uses this
to help inflate its compression figures.  SCHECK reports the file space
as number of clusters used, which is a 4096-byte average per file.  So
on my drive (Mostly ZIPS, I know I'm silly.) it claims 1.4:1 compression
but it's only about 1.1:1 right now.

I'm less satisfied with stacker now than I was before I realized this
inflation of its compression figure... <sigh>
-- 
|Jeff Epler               Additions Welcome           c(-8 ;-) >{8-) |
| :) (=( =-] (-= Celebrating the variety of faces =-> :^) {-= |-) (: |
| >X^P 8-[                                       __ Lincoln, Nebraska|
|   						 \/ IRC Synger       |