From owner-freebsd-fs Mon Apr 29 13:21:54 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA09133 for fs-outgoing; Mon, 29 Apr 1996 13:21:54 -0700 (PDT) Received: from novell.com (prv-ums.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA09108 for ; Mon, 29 Apr 1996 13:21:43 -0700 (PDT) Received: from INET-PRV-Message_Server by fromGW with Novell_GroupWise; Mon, 29 Apr 1996 14:21:20 -0600 Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Mon, 29 Apr 1996 14:27:38 -0600 From: DARREND@novell.com (Darren Davis) To: freebsd-fs@FreeBSD.ORG, pvh@leftside.its.uct.ac.za, merblich@ossi.com Subject: Re: Compressing filesystem: Technical issues - Reply Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>> Mitchell Erblich 4/29 12:51pm >>> >Peter and et al, > > I would taker in consideration what is the typical type of > file would be compressed and what is the benefit vs the tradeoffs. Disks > are already too slow, isn't the overhead of just uncompressing the blocks, > on demand in a random access pattern add a delay to the fs object. However, > I will proceed with the assumption that this approach may have some merit. Actually, systems tend to be I/O bound more than compute bound. By compressing a file, you potentially are trading off I/Os for CPU cycles (A good tradeoff I believe). Your I/Os will be smaller, but the CPU must expend cycles to uncompress it. I have seen on some systems with fast CPUs and increase in system performance due to the smaller I/Os involved with compressed files. Darren R. Davis Senior Software Engineer Novell, Inc.