Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!metro!macuni!sunb!ifarqhar From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) Newsgroups: comp.sys.amiga.misc Subject: Re: A compression filesystem Message-ID: <1213@macuni.mqcc.mq.oz> Date: 13 Feb 91 13:11:54 GMT References: Sender: news@macuni.mqcc.mq.oz Organization: Macquarie University, Sydney, Australia. Lines: 72 In article cpc@czaeap.UUCP (Chris Cebelenski) writes: >Here's an idea I've been tossing around: > > FCFS: Fast Compression File System > How it would work: > Basically, you MOUNT it just like any other device, > and it works just like any other drive would, EXCEPT that > it access a pre-allocated disk-file on your hard drive (Pseudo > device, a real device would be more difficult to implement due > to different HD controllers.) This "drive" (called DC0: maybe) > would look just like a regular Amidos disk to applications, but > anything stored on it would be compressed (LZW or whatever) rather > than stored "straight." I do not think you are differentiating between a handler and a device here. The device driver deals with the hardware, in this case accessing the disk physically. The handler adds the file system over the top. As such, you really only want a handler, you can use the current hard disk drivers, or the trackdisk.device for floppies. > Advantages: No special "data decoder" or headers required to > de-compress files when they are loaded, the device takes care > of it itself. Reduced storage needed for seldom-changed files. > Pseudo file can be backed up just like any other file. No headers? Depends on what compression system you use. A standard huffman encoder becomes quite a reasonable encryption system if you forgot the decoding tree. You also probably need an index (see later.) No data decoder? I presume that you mean hardware, because you are sure going to need something (hardware or software) to turn your file back into raw data. > Disadvantage: Possible that a pre-allocated chunk of your drive > needs to be set up. Possible slow write speeds, depending on > depth of compression. ( A good algorithm should keep the read > speed at a reasonable rate.) Definate slow write speed, and read speed. Additionally, random seeks become very difficult, and you will either have to decompress the file from the start and roll forward to the point, or have some sort of index. The later would probably be a good idea, as many compression systems read bit streams divided up into variable length parts, and if you lose part of the file, it is often very difficult to reconstruct past that, and definately impossible if the system is adaptive (arguments welcome on this last point.) You should also consider that many compression systems need large amounts of memory, for storing tables and so forth. Usually, the more memory they are given, the better their compression gets, and the slower they get at compressing. The run time-requirements of such a compressing handler may be very significant. Adaptive compression systems are the worst, and it is an adaptive system that would probably need to be used as multi-pass compressors would be somewhat inconvenient in this application. > Anything else I might have forgotten to take into consideration? > Anyone want to volunteer to write this beastie??? (Heh heh, why > is everyone looking at me so strangely??) Excuse the sound of hysterical laughter... :-) You will notice that so many PC hardware products that function as has been suggested have failed dismally, usually taking the company with them. One of the commonest causes, I have read, was the number of damage suits leveled against the manufacturers for lost data. -- Ian Farquhar Phone : + 61 2 805-9400 Office of Computing Services Fax : + 61 2 805-7433 Macquarie University NSW 2109 Also : + 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au