From: edwanji@matt.ksu.ksu.edu (Edwanji Lemorian) Subject: Compressed filesystems Date: 15 Apr 1993 11:16:43 -0500
This is a thought which just came to me. I don't know whether it's
been proposed before. I've noticed the main concern with 'compressed'
filesystems is demand-paging. It would seem to me that a good solution
to this concern is to compress files in 4k blocks (I think linux pages
in 4k blocks. My entire knowledge of linux specifics comes from this
group) These compressed blocks could then be fit into a number of
smaller-sized (1k or 512 byte) physical blocks.
This would be slightly complicated because while physical disk-usage
would be kept track of on a 1K/512 level, the files would be kept
track of (what English skills) on a 4k level. Each I-node then would
give information on a 4k chunk of a file and would possibly show:
1: the physical block to start on
2: the number of contiguous physical blocks this chunk is stored on
3: whether or not this chunk is compressed
4: number of bytes in the un-compressed chunk. This would be both for
the last chunk of a file, and possibly for pages of executibles so
that padding won't be un-nessisarily compressed and stored.
5: possibly a checksum to ensure data integrity
Some concerns about this method:
Since pieces must be stored in nunbers of contiguous (is that the
right word?) physical blocks, fragmentation may become a problem. I.e.
freed sections near the front of a partition will be too small to hold
larger compressed chunks so they must be moved to the end. (This was a
concern of mine with an idea someone posted earlier about compressing
the 'physical' blocks on a disk) But I don't know much in this area,
so that may not be a problem.
Speed of access. This would only be a problem depending on what is
stored under the filesystem. If it is text/source files. Then speed
would not be a major concern. Even if it is exicutibles, as long as
the time taken to un-compress the chunks won't have a major impact on
preformance, it still won't be a big concern. Obviously, you wouldn't
want to put a swap file in this kind of filesystem :-) (Unless having
a larger swap space is a much larger concern than the large
performance loss that would be incured)
Any comments? Any information/assumptions I have incorect that would
make this infeasible?
-- Edwanji Lemorian