Article View: comp.sys.next.misc
Article #4678Re: Drive drive
From: Christopher Kane
Date: Mon, 25 Jan 1993 20:56
Date: Mon, 25 Jan 1993 20:56
66 lines
3352 bytes
3352 bytes
In article <1993Jan25.121021.1787@macc.wisc.edu> anderson@macc.wisc.edu (Jess Anderson) writes: > In article <SCOTT.93Jan24203511@nic.gac.edu> > scott@nic.gac.edu (Scott Hess) writes: > >In my experience, zip (or gzip) would reduce the disk needs > >by up to %40, which is a pretty substantial improvement. Furthermore, > >compression is free and works even if new disk space is purchased, > >so investment in a reasonable compression scheme is going to keep > >paying back in the future. > > Unquestionably better compression technologies are a wise > investment. They pay back not only for the servers, but for > the user community as well, because most of us are anything > but swimming in extra disk space. > > There are significant labor costs in this dimension too. > F'rinstance, were I to update my MS-DOS archive, which is > stored on 800 floppy disks, from ARC to ZIP, I'd be looking > at the time it takes to do this on a 12 MHz AT clone, > feeding the disks one at a time. [...] Another benefit of compression, not mentioned yet, is that it could reap benefits _immediately_. Even if the schools can accept the gift of disk space, it may take quite a while for whatever process needs to be gone through to complete, plus additional time to install/setup the new drive. Also, Jess's example, while I can sympathize with it, having once converted a mere 50 full floppies to a new compression scheme, is perhaps somewhat misleading. Floppies need constant attention to feed them, as he notes, but the hard drive does not. A script could easily be set up to travel through the archive, replacing compressed files with their gzip'd counterparts. An informal test that I ran earlier today indicates that a wholesale conversion of the archives from compress to gzip may immediately generate 80-110 MB of free space on the disk, taking perhaps one CPU-day (a questionable unit of work, I admit). Some of the data: sonata.cc> du 1.0-release ; no compression 26488 1.0-release/source 30004 1.0-release/binaries 4835 1.0-release/demos 61330 1.0-release sonata.cc> du 1.0-release ; compress (current) 9366 1.0-release/source 16388 1.0-release/binaries 2580 1.0-release/demos 28337 1.0-release sonata.cc> du 1.0-release ; gzip -9 6373 1.0-release/source 12069 1.0-release/binaries 1978 1.0-release/demos 20423 1.0-release [I chose the 1.0-release directory as a representative sample of source and binary files. Obviously, some other types of files, tiffs for instance, will compress more or less than any "average" implied here.] Of course, actually getting someone to do this will probably being like getting someone to pull their own tooth... I don't mean to say that people should stop sending pledges to Jess. As noted before, simple re-compression is a solution with a finite lifetime. Christopher Kane kane@sonata.cc.purdue.edu
Technical Details
Message-ID:
<C1FGu4.EzF@mentor.cc.purdue.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!destroyer!gatech!purdue!mentor.cc.purdue.edu!newsReferences:
<1993Jan25.121021.1787@macc.wisc.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.misc Path: arc1-ca.pugleaf.net!sparky!uunet!destroyer!gatech!purdue!mentor.cc.purdue.edu!news From: kane@cs.purdue.edu (Christopher Kane) Subject: Re: Drive drive Message-ID: <C1FGu4.EzF@mentor.cc.purdue.edu> Sender: news@mentor.cc.purdue.edu (USENET News) Organization: Purdue University References: <1993Jan25.121021.1787@macc.wisc.edu> Date: Mon, 25 Jan 1993 20:56:25 GMT Lines: 66