From: weberj@dia.informatik.uni-stuttgart.de (Weber) Subject: Re: Stacker like file system Date: Mon, 31 Aug 1992 12:46:12 GMT
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 <--
For (de)compression use the LZW algorithm with variable size
(look at the sources of compress to learn how to do it). If
you use block sizes of 4K it should be easier as in compress
as you don't have to recycle codes (every block is done inde-
pendently so a code table of 4K is always enough for a block of 4K).
I think the main problem in doing this is that the compressed
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.
Initially each block has a "not yet written" flag. On second
write the old location is added to the free list again (and
merged with neighboring free blocks if possible).
Blocks that can't be compressed should be written unchanged.
Reading should be easy. Just look up its position in a Block
Allocation Table (an array of pointers to compressed blocks).
But what should df tell? I think the double of the physical
amount. But there may be problems with blocks that can be
compressed not or only little (e.g. *.Z). I think superstore
signals a write protect error if the superstore partition is
full ?
--Juergen G. Weber Student am Institut fuer Informatik Universitaet Stuttgart - Germany