In article <1993Apr14.122356.27773@kf8nh.wariat.org>, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:

quoted text
> The "proper" way to do a compressed filesystem is in fact not a compressed
> *filesystem* at all, it's a compressed *disk*.  Which means that individual
> blocks are compressed regardless of contents.  Since *ix does updates on
> entire blocks in all (current) cases, this imposes only a decompression speed
> penalty on demand paging.

Not really.  For example, I might want the directory structure to
remain uncomressed for speed, and I might want to have a quick
compression routine apply to most files for speed but with the option
of doing a slower, more thorough compression on some large, seldomly
changed files.

The biggest problem with a compressed disk is that as the data on the
disk changes, its capacity will vary - some files can be compressed
more than others.  This means that either the filesystem must be aware
of the disk compression system, or that the compressor be aware of the
filesystem structure.  For example, SuperStor and Stacker for DOS do
this - they fill up the filesystem allocation table with dummy used
blocks to change the apparent size of the filesystem according to the
real free space left.

Compression at the filesystem level offers far more flexibility, and -
perhaps more importantly - it is less likely to corrupt your entire
filesystem.

Cheers,
 Stephen Tweedie.
---
Stephen Tweedie <sct@uk.ac.ed.dcs>   (Internet: <sct@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland.