Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.development Subject: Re: Compressing file system ? Date: 10 Aug 1993 22:05:39 GMT Organization: University of Maryland Lines: 35 Message-ID: <24963j$86a@umd5.umd.edu> References: <2464r6INN4es@gap.caltech.edu> <johnh.744931465@ficus.cs.ucla.edu> <248jqmINNkq8@dell.kent.edu> NNTP-Posting-Host: roissy.umd.edu In article <248jqmINNkq8@dell.kent.edu> greg@usenet.mcs.kent.edu (Greg Spiegelberg) writes: >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? NFS is a protocol that declares how the client and server talk. It has fundamental file operations in it like read, write, create, delete, etc. It doesn't contain anything like "read this disk block". To comply with the protocol, the server would have to uncompress the data before sending it to the client. >What if the next compile of your kernel you forget to put in the compression >and don't realize it till after the reboot? The same thing that happens if you don't configure the device driver for the disk your files are on-- you boot the backup kernel. You DO have a backup kernel, don't you? :) >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? You could build a daemon that compresses stuff in user mode. But what if somebody kills it? Well, you build it in such a way that the daemon always leaves things in a recoverable state. For example, UFS does some things in certain ways that make the filesystem easy to fix after a crash. >The whole thing seems to be a bit risky to me. If you build a thing that works right, there's no risk. If the UFS code didn't work right, it could trash your data just as efficiently as any compressing filesystem.