From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: Undelete for linux? Date: Sat, 31 Jul 1993 05:33:32 GMT
In article <23bjd0$p6v@fnnews.fnal.gov> rohrer@fncrd6.fnal.gov (Keith
Rohrer) writes:
>Depending on
>the operation, and the compression scheme, there could be a severe performance
>hit if you modify record 1 of a 400 megabyte database--WHICH IS WHY I INSISTED
>ON USER OVERRIDE FOR THE COMPRESSION-DECISIOUN HEURISTIC. If
>compression makes using the file the way you want to use it too slow,
>set it nocompress. Besides, compressing chunks of a certain size
>independently will minimize that loss--
Hmm, most of the talk that I've heard about the compressed file system
basically said that 8k blocks (to pick a number) would be compressed
into some smaller amount of disk space. There would be gaps between
the records, sure, but it would provide a good way to know where
various parts of the file live w/o having to do an insane amount of
computation when a use touches a few bytes in a huge file. Depending
on the allocation scheme, you could also grow or shrink parts of the
file at the expense of making the file non-contiguous.
True, there may be times when you'll want to turn off compression, but
I don't think that touching a small part of a large file would be one
of them. Large files have the most to gain my compression, so any
reasonable compression scheme would take this into account. Any
compressing file system that doesn't work with large files would be
less than useful.
Now, there are other issues that would stop a compressing file system
from working. For example, the way the code is setup now, you'll have
to have the compression in the FS code, rather than in the driver.
Otherwise you'll have to chose an arbitrary limit after compression.
Basically, compression is a side wort that each FS type would need to
know about if it is to be maximally useful.
Also, for floppy drives, and possibly many hard disks as well, it
would take less time to decompress the file that has been read in than
it would to read in the larger file. I/O time still takes about
forever compared to memory operations.
Warner
-- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety.