Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!whitman.BITNET!HOWELL From: HOWELL@whitman.BITNET (DAVE HOWELL) Newsgroups: comp.sys.amiga.misc Subject: Re: a compression filesystem Message-ID: Date: 19 Feb 91 15:44:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 32 Date sent: 19-FEB-1991 08:39:12 >Not quite. One approach still makes sense (this is something I was >thinking of doing for several years, but it doesn't look like I'll >ever get to it): have a "compression file system" which works on >top of the regular one, so that individual files can be read/written >as compressed files transparently. > >This lets all compressed files be directly visible to all programs, >something you can't really get any other way. There's still the performance hit problem. How about .5 compression filesystem? I'll run a compressor program (zoo would be good, lharc would make me happier) on most of the stuff on my hard disk, particularly the stuff that I don't think that I'll use any time soon. Six weeks from now, I'll call it up in a program, and the file system will notice it's compressed, and uncompress it. The first access is thus slow, but future access is uncompressed. Now, I'm a little short on room, so I run the autosqueeze program, which finds all files that haven't been accessed in n days (14 perhaps) and compresses them in the background. It's the automatic decompression that is the critical advantage of such a filesystem. With data files (say, my 120K book data base) the performance hit on a compressed file could really hurt. One-time decompression seems a more reasonable solution. | Dave Howell bix: dhowell | | User Support Specialist Bitnet: HOWELL@WHITMAN | | Whitman College Internet: howell@whitman.bitnet | | "I'll get you a Satanic Mechanic." - Frank, Rocky Horror Picture Show |