When you install Stacker, you have a two choices: "incremental" or "free
space" installation. Incremental installation means that it takes existing
data on your disk and compresses it into the new Stacker disk as it creates
it. The manual said that 1MB of free space is required for an incremental
installation (yeah, if I had 1MB of free space, I wouldn't have bought Stacker
:-), and so I chose to do a free space installation.
The procedure was fairly easy, although it was a bit scary because the Stacker
manual doesn't really address a small disk configuration like one needs for
the UltraLite. I did a backup of everything, deleted everything except
COMMAND.COM, AUTOEXEC.BAT, and CONFIG.SYS, disabled TSRs as instructed, and
then proceeded using Stacker's INSTALL program.
Stacker leaves a minimum of 100KB of uncompressed space on the drive on which
you are creating the Stacker drive. I wish that it had an option to leave
somewhat less space, but I didn't see any way to convince it to do so. More
on this later.
If you're creating a Stacker drive on a boot volume, then it leaves
COMMAND.COM, AUTOEXEC.BAT, and CONFIG.SYS in the uncompressed area, and it
also examines CONFIG.SYS and leaves any referenced drivers in the uncompressed
area (I didn't have any drivers in CONFIG.SYS).
The installation program gives you an option to swap the drive designators
after boot time so that the Stacker drive will appear to have the same
designation (e.g. "C:") as it did before the installation. I opted not to do
the swap, and instead modified various files on the new drive after restoring
the backup.
It all worked fine. Stacker created a new drive, called it "E:" (recognizing
that "D:" was already in use), and the driver loaded right up when I rebooted.
I restored all of my files onto the E: drive and modified all configuration
files in which there were hard-coded "C:" references. By the way, I'm running
the MKS Toolkit in the configuration which runs init.exe instead of
COMMAND.COM as the initial shell after booting, and all of that worked OK too
(after a couple of tries).
I had originally intended to do a really detailed analysis as I went --
logging file sizes and running timing tests on various combinations of plain,
PKLITE'd, Stacker'd, and Stacker'd-PKLITE'd executables -- but I got impatient
and just installed the damned thing, so I can't really give you much hard data
on how much space was saved and how much CPU time is involved in the
compression and uncompression cycle. Here's what I can say about it:
Before I did anything, I had about 100KB free.
I changed the cluster size to from the stock 4KB to 1KB using Norton
utilities, and that freed up another 350KB for a total of 450KB.
After installing Stacker, I ended up with only about 300KB free on the E:
drive plus a little over 100KB on the uncompressed C: drive. I removed all of
the unnecessary Stacker stuff (they leave the installation and volume creation
stuff on the disk). That left me with about 600KB free on E: and 130KB free
on C:.
By the way, the 130KB on C: is real, but the 600KB free on E: is "projected"
free space based on compression estimates.
Thus, the delta between 4KB clusters and Stacker was about 630KB (nice!), and
the delta between 1KB clusters and Stacker was about 270KB (well, OK).
Interestingly, the cluster size change doesn't buy you much when you use
Stacker. Since it creates one big file for its disk space, the only real
savings from a small cluster size is realized in the uncompressed area. The
Stacker disk sets its own cluster size depending on the size of the Stacker
disk; it set mine to 4KB.
Most of my executable programs have been PKLITE'd, and just to see if double
compression was costing me space as well as time, I un-PKLITE'd about 500KB
worth. It grew by about 50KB, so I PKLITE'd them again.
As far as access time is concerned, I haven't really noticed a big difference.
The UltraLite isn't exactly a fast computer, but I've been happy with its
filesystem speed (RAM is faster than disk, after all). I did find one
interesting thing, though. I ran some tests running in which I loaded the
MKS Korn shell and had it do an "ls" command and return. The shell can't be
compressed using PKLITE because it an overlay of sorts, but the "ls" command
was compressed using PKLITE. Running it on the Stacker disk, it took between
4.3 and 4.4 seconds to load, run the command, display the output, and exit.
When I un-PKLITE'd the ls command, it took somewhat longer: 4.35 to 4.45
seconds. My guess is that the extra time was required for Stacker to
uncompress the larger ls.exe executable. Copying both the shell and ls
executables to the uncompressed drive C:, it took about 3.35 to 3.45 seconds
with a PKLITE'd ls.exe and 3.3 to 3.4 seconds with a normal ls.exe.
Lastly, I said that I'd get back to that 100KB+ on C:. What I did with it was
that I defined c:/tmp as my $TMPDIR for MKS. That way I always have a bit of
a safety net of free space whenever I need it. I'll probably also define a
uucp spool directory there for UUPC.
Overall recommendation: I'd say its worth the money, especially if you have a
lot of data files or a lot of programs which cannot be PKLITE'd because of
overlays. I paid about $85 for Stacker. You can probably shop around and get
it for closer to $70, I'd guess -- I seem to recall seeing it advertized for
that somewhere.
I'd be interested in hearing from other's experiences with Stacker or other
kinds of disk compressors.
--
-Brian Smithson
Motorola Inc., Computer Group, Commercial Systems Division
10700 N. De Anza Boulevard, Cupertino, CA 95014 USA, (408)366-4104
brian@csd.mot.com, {apple | pyramid}!motcsd!brian