Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!mmdf From: lou@vaxsc Newsgroups: comp.sys.amiga.misc Subject: (none) Message-ID: <44647@nigel.ee.udel.edu> Date: 14 Feb 91 17:05:02 GMT Sender: mmdf@ee.udel.edu Lines: 124 In article , Chris Cebelenski writes >Here's an idea I've been tossing around: > > FCFS: Fast Compression File System > > Purpose: Reduce storage needed for seldom accessed files. > > Implementation: Pseudo or real device driver. (Probably Psuedo) > > 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 for one love this idea! It seems to be the missing link for an idea I've been kicking around the past year or so, which is this (with above idea integrated) Anyone who has used the Computer Associates (yuk) product ARCHIVER on a VAX/VMS system will be famaliar with this notion. For those who haven't had the privilege (?!?) let me enlighten you. This product allows a user to move a file (or set of files) into off-line permanent storage for later retrieval. Use is simple, commands Archive and Retrieve are provided to the user. When the user has a file s/he wishes to remove from primary storage, but doesnt want to delete, s/he gives a command similar to the following: archive /until= /log then the file is moved into a queue for later archival. Once a day a job runs which moves all queued files to tape storage. The product uses a proprietary tape format, and compression methods to reduce the tape overhead. If the user decides s/he wants the file back, s/he gives a command something like this: retrieve /log and a request is made for an operator to load the tape, and the file is placed wherever the user wishes. Now how about this variation for the Amiga. Using the above idea (a psuedo-device) as a primary archive device, where all i/o is done with a compression/decompression routines, built into the device driver, a series of commands could be built that would allow the user to archive/retrieve files at will. The files would be queued and the user can set up when s/he wishes the queue to be emptied, and files flushed to archive storage. By using a psuedo device, floppies can be used, with a proprietary format which will attempt to store maximum density to them, and allow for splitting files across disks. When a disk is inserted, it will be tossed out by AmigaOS, but recognized by the psuedo- driver (much like CrossDos or MSH). When a user wants a file back they do something like the following archive /directory /log and the queue file (online) is searched, and a listing of archived files is produced. If the user decides s/he wants a file back off of archive storage, then something akin to the following can be issued : retrieve /log and the utility will prompt the user to enter archive floppy where is the number / label assigned to that archive disk. Finally, one could set retention dates for files, so that stale- dated files could be deleted. This would require compressing the floppies with some related utility, where the queue file would be searched, and stale-dated files would not be copied to new floppies. All retained files would be copied. This would allow the user to clean up stale-dated files, and reduce floppy overhead. The psuedo-device would take care of the archive/retrieve having to worry about compression, all they would do is maintain/examine the queue file (kept online), and advise the user. The psuedo- device could also take care of the "messiness" of using a non-standard disk format, by automagically recognizing the disk, and interpreting system calls to it, like CrossDos or MSH does. I'm not a fan of non-standard disk formats, but it would allow for some very intense compressions and greater storage ability. So, anyone want to try this? I've put together some ideas on implementation, but I haven't had time to learn/code anything for it. Remember also, that the above commands and formats are used by Computer Associates, so it would have to be suffeciently different to avoid copyright infringements, and with Lotus now doing their best to demolish the computer software industry, you may even have to worry about "look and feel" (Disgusting, isn't it?). Just food for thought, if you have flames, buy a fire extinguisher, your local K-Mart has them for about 10 bucks. If you have suggestions I'd love to hear them, as long as they're constructive. Sorry this is so long, its a long-winded idea. ---------------------------------------------------------------- -Lou Williams Via Bitnet : william8@niehs.bitnet Via Internet: lou@vaxsc.niehs.nih.gov Computer Sciences Corporation, Research Triangle Park, NC ---------------------------------------------------------------- -Sometimes in order to feel better about yourself, you have to make others feel bad, and I'm tired of making others feel good about themselves. -Homer Simpson. ---------------------------------------------------------------- All opinions are mine, as if you really wanted them. Archiver is a Trademark of Computer Associates. VAX/VMS is a trademark of Digital Equipment Corporation.