From owner-freebsd-hackers Tue Feb 27 19:41:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA10752 for hackers-outgoing; Tue, 27 Feb 1996 19:41:12 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA10738 for ; Tue, 27 Feb 1996 19:41:06 -0800 (PST) Received: from phaeton.artisoft.com ([198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id TAA20648 for ; Tue, 27 Feb 1996 19:41:05 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA06835; Tue, 27 Feb 1996 20:27:48 -0700 From: Terry Lambert Message-Id: <199602280327.UAA06835@phaeton.artisoft.com> Subject: Re: OK, so what would YOU like to see on that second CD? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 27 Feb 1996 20:27:47 -0700 (MST) Cc: terry@lambert.org, jfieber@indiana.edu, jerry@border.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199602272300.AAA04556@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 28, 96 00:00:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I have some example file compression code for the Heidemann framework; > > John has asked that I not redistribute it. > > but the problem is not the compression code, there's plenty of it > out there, and some is even reasonably fast [and often the same > algorithm has been patented several times by different people, > *after* an implementation was made available on the net; I was > reading the comp.compression FAQ the other night and it's full of > this kind of stories! ]. The problem is that compressed blocks > have variable size, and handling them efficiently requires (I > believe) big changes in the device+fs code. Perhaps log-structured > filesystems lend themselves better to this. The code that John's students wrote for their project compressed and decompressed on a file basis, so this isn't a problem, at least for file compression. > > It would be trivial to implement block compression at the device export > > layer in the devie framework I suggested previously. This is similar > > while you can certainly make a compressed device look like a regular > one, I believe some efficiency is lost, and not only because of > compression. The FS layout assumes that adjacent blocks are adjacent > (modulo a few bad sectors). But what on a compressed device ? It's pretty clear that you need a block-addressable variable granularity block store for this type of thing. Such a block store would be *extremely* useful for all sorts of things, like attribution, and not just compression. 8-). I think if you cared about speed, you'd buy more disk. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.