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