From: keith@ksmith.com (Keith Smith) Subject: Re: New feature for the filesystems. What do you think ? Date: Fri, 16 Apr 1993 03:33:56 GMT
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.
>
Am I nuts here? Seems like you just need a layer of code between the
virtual disk your filesystem see's, and the physical media. This code
can maintain and map multiple compressed blocks (say 4K) into physical
uncompressed block numbers used by the filesystem code. The only trick
I see is having a filesystem that has a dynamic size. This should not
be insurmountable either, as one could define the size of the virtual
disk as arbitrarily 3X, and then use a non-removeable psuedo file entry
to eat up any unavailable space, or reduce it's psuedo "size" from 2X
the disk as successful compression kicks in. In this way you always see
"real" space available, but space in use would be dynamic shifting from
the pseudo file to real files and back as compression occurs or
compressed space is free'd. For any kind of data integrity compression
should be done on a block by block basis (4K at least), but perhaps with
n smaller sub-blocks (256bytes?) being sqeezed into each block. That
way a trashed block won't kill you for more than 16K of data (@4:1).
For example the filesystem wants block #20, hands off to the virtual
translator which looks in a table and finds virtual block 20 is offset
512 characters in physical block 3. It fetches it, uncompresses it, and
delivers the appropriate chunk of data back.
In the reverse, if the virtual block won't squeeze back in, it will have
to drift onto a different physical block until it fits. Just like a
variable length ISAM file record. Hell design the directory structure
and file system as a B-tree variaton. Oooohhm, It's *LATE* yawn, and
I'm rambling ....
-- Keith Smith keith@ksmith.com 5719 Archer Rd. Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201 Somewhere in the Styx of North Carolina ...