*BSD News Article 19355


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