In article <1992Aug31.124612.1328@ifi.informatik.uni-stuttgart.de> weberj@dia.informatik.uni-stuttgart.de (Weber) writes:
quoted text
>I think there is a way to implement a stacker like file
>system without having to change much of the kernel.
>
>Hook the low-level routines for reading/writing one block
>from/to disk and insert a compression algorithm between.
>
> natural-size  -----> compression ----> compressed block
>               <----- decompression <--
>
>blocks have a "random" size <= 4K and you encounter the same
>problems as with memory management. To write you have to look
>for a fitting free space on the free list by doing some of the
>XXX-fit strategies. If there is not enough free space at one
>continuous location you even may have to do a kind of garbage 
>collection.

You hit the nail on the head.   Indeed, variable sized blocks is
what makes a compressed file system harder then a normal files system.

In ACF (automatically compressed format) I am handling this by 
allocating what I call mini-blocks to represent the compressed block.
Right now I divide each physical block up into 8 mini-blocks.  
Mini-blocks are clustered together into a sector, which is made 
up of 8 blocks or 64 mini-blocks.

A compressed block is represented by a sector pointer, and up to 8
mini-blocks which are all allocated within the same sector.   An in
core sector map containing the availability of mini-blocks is
maintained for each sector. (This suplements a bit map structure,
which is used to allocate the actual mini-blocks. 1bit for each
miniblock).

A smaller mini-block size might be appropriate, but this is tunable
parameter.  I think stacker uses a similar scheme, but there are
16 mini-blocks in a real block. 

quoted text
>But what should df tell? I think the double of the physical

You can predict the availability of free space by maintaining
the current compression stats;
quoted text
>-- 
>
>Juergen G. Weber
>Student am Institut fuer Informatik
>Universitaet Stuttgart - Germany


-- 

-shawn