From: chuckm@canada.hp.com (Chuck Munro) Subject: Re: New feature for the filesystems. What do you think ? Date: Wed, 14 Apr 1993 00:12:36 GMT
Ronnie Sahlberg (ronnie@lysator.liu.se) wrote:
> Would it not be great to be able to compress/gzip all files
> on the filesystem and still have the files behave like they
> were uncompressed ???
===================
This is a great idea, and now is a chance for some brave soul to do it
right, rather than using one of those strange DOS-based compression
schemes. :-)
I am aware that some *real* standardization work is being done as we
chat (sorry, don't know where). I heard ISO and/or ANSI was involved.
A standards body is dealing with the possibility of having intelligent
compression take place for magneto-optical read/write disks. The idea
is to do as you suggest in your post .... place a marker in the inode
to indicate the file is compressed. That way, you can have both types
of files concurrently in the same filesystem.
An interesting offshoot of this is the use of a compression chip right
in the disk controller. The chip is smart enough to recognize inode
structures as the data is read from the disk. If it sees the compression
marker, it de-compresses the data in the file *in_hardware* and clears
the compression marker before the inode data is passed to the CPU.
If the same disk cartridge is mounted in a non-smart disk drive, the
kernel code for the filesystem gets the inode structure unmodified, and
does decompression in software instead. Furthermore, if your filesystem
code can't decompress a file written by another, you can simply 'cat'
the file through a standard decompressor command to recover the data.
Neat idea! The important thing here is that the *file* data is com-
pressed, *not* the inode data. This is quite unlike the DOS schemes.
Such an ISO/ANSI filesystem is also portable by design, since filesystems
created on any computer can be mounted by any other compliant system.
If someone is tempted to try this, I'd like to suggest that now would
be a good time to investigate any possible emerging standards *before*
creating the filesystem code. Since Linux is headed in the POSIX
direction, keeping up with the standards would be a good thing.
My $0.02 worth, anyway.
Chuck.