From: goldfish@cebu.sbi.com (P. Goldsmith) Subject: Re: [Q] Compressed Filesystem? Interest? Date: 21 Jan 1993 01:46:43 GMT
In article <1993Jan19.110838.7734@black.ox.ac.uk> mbeattie@black.ox.ac.uk (Malcolm Beattie) writes:
>* an `open' on /Z/foo/bar.Z would open /usr/local/foo/bar
>and use its buffer to contain the compressing window on-the-fly.
>
>* read() produces the compressed stream from the real file
>
>* lseeks get ignored or are only allowed forwards (perhaps just
>make it behave like a pipe)
>
>* the filesystem would be forced to be read-only.
>
>The only thing I'm a bit unclear about is where the actual
>compressing gets done. To be more precise: ordinary file systems
>stick around in device wait until they get their data and don't
>hog CPU. If the compressing can't get done on behalf of the
>user process then scheduling problems might arise if the kernel
>sits there doing a compression algorithm every time you read().
There was recently a thread about this on the Apollo group. It seems that
this was implemented on the Apollo by just adding a new file type. The
Apollo file system is just a set of calls to external file handlers which
are called dynamically at file open time. Each file has an object type
which corresponds to the binary to execute.
This is a first step to a microkernel approach, which is opposite to the
Linux approach (monolithic kernel) the "micro" VS "monolithic" kernel debate
does not belong in this group; suffice it to say that the monolithic Linux
kernel is smaller than many microkernels.
The description I read for the apollo was that the file gets compressed
normally (using compress) then its object type gets changed to
"compressed-file", which is a sequential read-only object. the file appears
to be a read-only file and non-sequential operations on it fail. (this is
perfect for MAN pages, and sources.) Apollo also implemented their source
control tool the same way, "write" is analogous to the "check-in" operation
and the file (say "main.c") is called "main.c" for the newest one, and
"main.c/1", "main.c/2", ... for the older versions. The file system does
all the work and the source control is completely transparent.
Everything I am quoting is second-hand, I don't have Apollos to play with
any more. The point is, the strategy outlined above is very similar to one
already implemented on another platform.
>Maybe I'm worrying about nothing: how much overhead is there
>with NFS, for example?
try waiting for a blocking NFS (as implemented by Sun) sometimes ... :-(
--
Paul Goldsmith <goldfish@sbi.com> w (212) 783-7733
(shredding elf) <goldfish@ozrout.uucp> h (212) 727-9345
( Shirley MacLaine told me there would be LIFETIMES like this)
so many managers ... so little time ...