From: bcr@bohr.physics.purdue.edu (Bill C. Riemers) Subject: Re: New feature for the filesystems. What do you think ? Date: 15 Apr 1993 03:08:15 GMT
In article <SCT.93Apr14235111@damsay.dcs.ed.ac.uk> sct@dcs.ed.ac.uk (Stephen Tweedie) writes:
>In article <1993Apr14.122356.27773@kf8nh.wariat.org>, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>> 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.
Actually I was thinking the best way would not be to have new file system,
but simply to use existing tools. One stradegy I was thinking of trying, is
having a special bit to mark files as special. Then you could do something
like compress a directory, and replace all the files with one special file
hard linked to all the names of the files that where there. Then with a
command like "ar" you place the compressed libraries in a random access
library. Then when "open" sees that your special bit is set, it would
follow the instructions in the special file for restoring the uncompressed
version before trying to access it. I don't know how efficient such a
method would be, but it seems like less work to impliment that a whole
new file system.
Bill