From: cgy@cs.brown.edu (Curtis Yarvin) Subject: Re: 'pklite' for Linux. Date: 19 Mar 1992 01:12:39 GMT
In article <danielce.700817239@ee.mu.OZ.AU> danielce@ee.mu.OZ.AU (Daniel AMP Carosone) writes:
>phr@soda.berkeley.edu (Paul H. Rubin) writes:
>
>>Actually there IS another alternative, which is perhaps not in the
>>spirit of Un*x but may be practical: put the decompression code in the
>>FILE SYSTEM (through vfs). Then we could add additional decompression
>>algorithms, etc., by adding vfs drivers. The FS would recognize
>>files with a "compressed" bit set; these files would be read-only
>>and sequential-access-only.
>
>This is certainly the most general solution.
Nachpt. You could also put it in the disk driver, a la Stacker. This would
have the advantage of cleanliness, though you'd only get page-by-page
compression.
But... naah. I think it would actually do best in the buffer cache.
Whenever you load a chunk of data in, you decompress it; whenever you store
it back, you recompress it.
>I'm unsure why this is not in the spirit of Unix. Especially, if we
>have VFS why waste the opportunity for a simple, general solution?
>
>I'm also not sure I see why the files have to be either read-only or
>sequential-access only.
Random access shouldn't be a problem, but from what I know of compression
algorithms writing is. Most files on a system are only read, anyway, so
this shouldn't be much of a problem.
c