home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.msdos.apps
- Path: sparky!uunet!rei2!fox
- From: fox@rei2.uucp (Fuzzy Fox)
- Subject: Re: Stacker
- Message-ID: <1992Jul31.194848.17559@rei2.uucp>
- Date: Fri, 31 Jul 1992 19:48:48 GMT
- References: <2095@ncr-mpd.FtCollins.NCR.COM> <7178@ds5000.DAC.Northeastern.edu> <1992Jul30.164625.14719@progress.com>
- Organization: REI
- Lines: 24
-
- leary@progress.COM (James Leary) writes:
-
- >Another point that people may overlook: when using Smartdrive or other on-
- >board disk-caching method, Stacker does not utilize it well, if at all. I
- >believe it has something to do with Stacker intercepting disk interrupts
- >BEFORE the cache has a chance to see them.
-
- That's not quite it; the Stacker software, due to its compression of
- individual sectors, ends up spreading virtual sectors around the disk,
- due to fragmentation within the Stacker volume. Thus, cache programs
- that expect sector 121 and sector 122 to be located physically next to
- each other come out wrong. However, cache programs don't normally cache
- a Stacker volume, but the principal applies to the uncompressed volume
- as well...If a program reads several adjacent sectors from the Stacker
- drive, it can translate to several UN-adjacent sectors within the
- stacker volume, thus defeating the locality-of-reference principal that
- most cache programs depend on. Use the SDEFRAG utility occasionally,
- and you may find some performance improvement.
-
- --
- #ifdef TRUE | Fuzzy Fox fuzzy@netcom.com
- #define TRUE 0 | a.k.a. David DeSimone an207@cleveland.freenet.edu
- #define FALSE 1 | "This article was probably generated
- #endif | by a buggy news reader."
-