Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!usenet.mcs.kent.edu!not-for-mail From: greg@usenet.mcs.kent.edu (Greg Spiegelberg) Newsgroups: comp.os.386bsd.development Subject: Re: Compressing file system ? Date: 10 Aug 1993 12:53:28 -0400 Organization: College of Business Computer Lab, Kent State University Lines: 19 Message-ID: <248jqmINNkq8@dell.kent.edu> References: <vp.744825872@news.forth.gr> <245orp$e2f@europa.eng.gtefsd.com> <2464r6INN4es@gap.caltech.edu> <johnh.744931465@ficus.cs.ucla.edu> NNTP-Posting-Host: dell.kent.edu >>Its nice to see all this talk about a compressed file system, but perhaps the >>more important question is has anyone actually attempted to implement any >>sort of compressed file system besides tcx? This subject is way out of my league, but I have a couple questions. Wouldn't putting the compression in the kernel cause conflicts with machines that nfs the compressed volumes? Wouldn't they also need the same drivers in their kernels unless the same algorithms were put into the nfs source? What if the next compile of your kernel you forget to put in the compression and don't realize it till after the reboot? If the compression util's weren't put into the kernel but into a daemon of some sort wouldn't that be taking an aweful risk with your data? The whole thing seems to be a bit risky to me. But then, as I said, this subject is way out of my league. -Greg