Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!news.claremont.edu!ucivax!ucla-cs!ficus.cs.ucla.edu!johnh
From: johnh@ficus.cs.ucla.edu (John Heidemann)
Subject: Re: Compressing file system ?
Message-ID: <johnh.744999634@ficus.cs.ucla.edu>
Sender: usenet@cs.ucla.edu (Mr Usenet)
Nntp-Posting-Host: nottingham.cs.ucla.edu
Organization: UCLA, Computer Science Department
References: <EgN6R_K00WB5JOZpRc@andrew.cmu.edu> <1993Aug9.233341.20631@fcom.cc.utah.edu>
Date: 10 Aug 93 16:20:34 GMT
Lines: 45
terry@cs.weber.edu (A Wizard of Earth C) writes:
>[ List of problems doing block-level compression
> and doing compression via an NFS server deleted.
> Complaints are: (1) the NFS server lacks information about
> the use of the file so it will do bad things, (2) compressed
> blocks don't map cleanly on to a disk with fixed block size,
> (3) you need somewhere to store a ``{,not} compressed'' attribute.
Problem (2) and the complexity of managing per-block compression
information have convinced me that I would do whole-file compression
if I were to do a compression file system (layer). I'm would hope
that problem (1) can be finessed by proper tuning and relaxation of
semantics. Problem (3) is a real one, but is amenable to a number of
hacks (for example, BSD 4.4 UFS has a number of new flag bits for each
file---just steal one.), and even a few real solutions.
>Perhaps the best implementation of a compressed file scheme I have seen was
>the one in the UCLA Ficus implementation in BSD4.4; it has many of the
>attributes I have tagged as "desirable" (noting that the aesthetics are
>dictated by teeny, tiny disks rather than clean kernel implementation or
>fast access).
Here I am somewhat confused. Ficus (which is only the replicated file
system) is not part of BSD 4.4; only the UCLA stackable layers
interface is included. Unfortunately, 4.4 does not include a
compression layer, just a null layer and a user-id mapping layer.
The SunOS implementation of UCLA stacking has at one time included a
prototype compression layer. This layer was done as part of a class
project by Geoff Kuenning and Steve Whitney. Unfortunately, as a
class project, though, it lacked some of the...reliability...one might
want before putting it in production use. (BTW, to relative to the
problems described above, it encoded the compression attribute in the
file name and compressed on block boundaries.)
>I'd encourage anyone who wants to get into building file systems to do so;
>there are very few live projects of this type out there, and I can count the
>number of commercial file system vendors (that's all they do) on one hand.
I'd have to agree with this. I'd love to see a good Unix
compression layer, among other things.
-John Heidemann
UCLA Ficus Project