From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Compression Plugin Date: Wed, 21 Sep 2005 10:31:13 -0700 Message-ID: <433198E1.3080006@namesys.com> References: <433017C1.4050408@gmail.com> <43307E49.8060404@slaphack.com> <433102D0.7010706@mch.one.pl> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" To: PFC Cc: reiserfs-list@namesys.com PFC wrote: > >>>> An interesting idea: select the algo and a range of compression >>>> levels per file, >>> > > A simple check on wether it's an already compressed file (using > file extension and magic number) should be quite easy to do and cheap. > > Now, intrigued by this lzo thingie, I ran a little benchmark on my > emails ; I have a huge mail spool and my mail client is always slow > to launch... > Seems that on this laptop LZO can compress about 40 MB/s and > decompress about 200 (!) MB/s. On the mail spool, compression ratio > was about 1/2 ; gzip was better, although 5-6 times slower. So > considering the disk throughput is only 15 MB/s, this could make it > twice as fast with CPU to spare. Yowza ! Yup. Yowza is what we want.;-) LZO is what Edward selected for us to use. > >>>> but select the actual compression level at flush time >>>> based on some estimate of how loaded the system is.. :) >>>> Probably not worth it even though the amount of compression and the >>>> speed differ greatly from -1 to -9... I hope no one wastes their time >>>> on it until the more important things are done.. but perhaps a nice >>>> touch. >>> >>> Kinda makes it sound like in addition to the "repacker" that repacks >>> blocks in order and squeezes them, (which should allow for filesystem >>> size reduction), there'll be a compression repacker too that allows >>> you to repack files to a higher or lower compression level (anyone >>> remember the Compression Agent that came with DoubleSpace and the like >>> in Windows 9x?). >> >> >> AFAIR e2compr patch to ext2 (which enables compression on a ex2 >> filesystem) could use many packing methods, including gzip and bzip2 >> (!), with a range from 1 to 9... >> >> I certainly could imagine cases where compression level is more >> important than speed. >> >> > > > >