From: pdh@netcom.com (P D H) Subject: Re: New feature for the filesystems. What do you think ? Date: Mon, 19 Apr 1993 06:11:34 GMT
rajat@watson.ibm.com (Rajat Datta) writes:
>Why not just build a compressed filesystem? That is, compress all the
>blocks, metadata and all. With MSDOS 6.0 coming with builtin
>compression, I suspect this will become rapidly become a "must-have"
>rather than a "gee-whiz" feature.
Because it makes a mess. Compression that does not get to take advantage
of the same kind of data in sequence, even when scattered on random blocks,
is just not going to do as good.
Then there is the random access issue. So what if a 1024 byte block has
been compressed to 512 bytes (or 400 bytes or 600 bytes). You have to
make use of the bytes that remain on the physical sector to gain anything.
The addressing becomes all distored and requires some complex logic to fix.
This form of compression gives distorted perspectives of what space you
have available and what space a file takes. A C program that takes up
40000 bytes will be reported as 40000 bytes this way, whereas a GIF file
that takes up 40000 bytes will also be reported as 40000 bytes, even
though it actually needs more real space.
I would highly prefer seeing the size of files being reported by the actual
real space need, and be able to do very rapid direct access to random
positions in a file. The solution is not simple, but I it does not seem
than the solution is an underlying compression system (I would put encryption
there, but not compression). I believe the compression problem needs to be
addressed in terms of file formats, or at a point near that issue. Perhaps
it should be in the standard library, but most certainly not in the kernel.
-- | Phil Howard, pdh@netcom.com, KA9WGN Spell protection? "1(911)A1" | | Right wing conservative capitalists are out to separate you from your MONEY | | Left wing liberal do gooders are out to separate you from EVERYTHING ELSE!! | +-----------------------------------------------------------------------------+