Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!pipex!sunic!news.funet.fi!klaava!klaava!not-for-mail From: lukka@klaava.Helsinki.FI (Tuomas J Lukka) Newsgroups: comp.os.386bsd.development Subject: Re: Compressing file system ? Date: 7 Aug 1993 16:31:53 +0300 Organization: University of Helsinki Lines: 21 Message-ID: <240as9$bdu@klaava.Helsinki.FI> References: <23rh55$ct@encap.Hanse.DE> <23tr2j$3tt@europa.eng.gtefsd.com> <23tsn3$7e@Germany.EU.net> <CBCJv4.8AC@sugar.neosoft.com> NNTP-Posting-Host: klaava.helsinki.fi In article <CBCJv4.8AC@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes: >In article <23tsn3$7e@Germany.EU.net> bs@Germany.EU.net (Bernard Steiner) writes: >> Note: I think the idea of an optional compressing filesystem is OK, I just see >> more potential problems than possible benefits. > >Coupla ideas: > > chmod +c filename -- allow compression on this file. > > I'd like a Zoo FS. You'd mount a Zoo archive on a mountpoint > and it'd maintain the archive through FS operations. Over at the inux side, we now have a 'userfs', a user-space filesystem type. On a 486-33, the transfer rates go in hundreds of kilobytes /second. I'm currently working (slowly, I have 'real' work to do) on a compressed file type for it, using 'blocked gzip'. The file has to be altered from the normal gzip form first, because otherwise it would be too slow, and then just mount a .tar.gz file. Tjl