From owner-freebsd-fs Tue Feb 27 18:20:15 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA06684 for fs-outgoing; Tue, 27 Feb 1996 18:20:15 -0800 (PST) Received: from virginia.edu (mars.itc.Virginia.EDU [128.143.2.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA06522 for ; Tue, 27 Feb 1996 18:19:55 -0800 (PST) Received: from archive.cs.virginia.edu by mail.virginia.edu id aa27636; 27 Feb 96 21:08 EST Received: from stretch.cs.Virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by archive.cs.Virginia.EDU (8.7.1/8.6.6) with SMTP id VAA14870; Tue, 27 Feb 1996 21:07:50 -0500 (EST) Received: by stretch.cs.Virginia.edu (4.1/SMI-2.0) id AA29786; Tue, 27 Feb 96 21:07:48 EST Date: Tue, 27 Feb 1996 21:07:45 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: Peter Stubbs Cc: Peter van Heusden , freebsd-fs@freebsd.org Subject: Re: Compressing filesystem for FreeBSD In-Reply-To: <6BD18783D77@aidan.staidan.qld.edu.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org Precedence: bulk On Wed, 28 Feb 1996, Peter Stubbs wrote: > On 24 Feb 96, Peter van Heusden wrote: > > > > > Does anyone know if anyone has done any work on writing a > > compressing filesystem for FreeBSD? I've been thinking about this, > > and the strategies to do it, and I'd like to know if there is any > > previous work out there I can refer to... > > > This isn't much of an answer, but since nobody else has said > anything I'll point out that the the nearest thing that's here now is the > pseudo-device gzip which allows gziped a.outs to be run. Perhaps all > that is needed is to extend that device to other files? > > I'd hate to see us go the same direction as MS-DOG and create a > single file with all the other files compressed into it. Perhaps the > netware 4 technique of compressing files that haven't been access for > a certain time using a (very) niced daemon? The real problem with compressing a file system that is often forgotten is that you are increasing the cost in CPU cycles for a disk I/O. While I have had dos/linux enthusiasts go on about how compressing your filesystem can both improve I/O bandwidth and increase available disk space, the cost is often fogotten. On a multi-user system, the CPU is not idle during disk I/O. I think there would also be problems with paging and reads in general. Which block of the disk contains the nth byte? In short, I don't see it being worth the effort. Adrian System Administrator for the NVL, NIIMS and Telemedicine labs adrian@virginia.edu ---->>>>| Support your local programmer, http://www.cs.virginia.edu/~atf3r/ --->>>| STOP Software Patent Abuses NOW! Member: The League for -->>| For an application and information Programming Freedom ->| see: http://www.lpf.org/