From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: New feature for the filesystems. What do you think ? Date: 18 Apr 1993 02:23:41 GMT
Keith Smith (keith@ksmith.com) wrote:
: In article <0fmuPUm00VopMZhFU7@andrew.cmu.edu> Frank T Lofaro <fl0p+@andrew.cmu.edu> writes:
: >Excerpts from netnews.comp.os.linux: 13-Apr-93 Re: New feature for the
: >fil.. HJ Lu@eecs.wsu.edu (463)
: >
: >>I am wondering how a compressed filesystem handles demand paging and
: >>random update.
: >
: >I had just posted wondering about demand-paging, but came up with an
: >idea. Have it uncompress the file, and put it on some temporarily
: >allocated inodes, and exec/demand page it from there. It would require
: >some changing of filesystem allocation/exec/demand paging routines I
: >gather, but should be feasible.
: >
: [ stuff about intermediate layer deleted. ]
I think someone already suggested this, but it got ignored..
PLEASE look into the structure of the LFS (log file system) written
for the Sprite OS. This is a journalling filesystem. This makes it
absolutely ideal for makeing a compressed file system. (not to mention
that the fact that it is very fast to write to, and nicely crash
resistant).
The thing that makes LFS so nice is that ALL writes are sequential.
inodes, directory, map blocks, data all get written sequentially into
the log. Makes compression kinda easy. If you byte-align the blocks,
and work with 8K pseudo blocks, then you never need to uncompress more
than 8K to get the data you want.
There was another benifit but I have forgotten it. Oh well. Some other
time.
michael.