Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!uunet!mcsun!Germany.EU.net!news From: bs@Germany.EU.net (Bernard Steiner) Newsgroups: comp.os.386bsd.development Subject: Re: Compressing file system ? Date: 6 Aug 1993 17:17:55 +0200 Organization: EUnet Deutschland GmbH, Dortmund, Germany Lines: 30 Distribution: world Message-ID: <23tsn3$7e@Germany.EU.net> References: <23rh55$ct@encap.Hanse.DE> <23tr2j$3tt@europa.eng.gtefsd.com> NNTP-Posting-Host: qwerty.germany.eu.net In article <23tr2j$3tt@europa.eng.gtefsd.com>, niemidc@oasis.gtefsd.com (David C. Niemi) writes: [...] |> smaller blocks/frags as you write them. I think you want to keep directory |> structures uncompressed, and you want to compress EVERY file that goes onto |> disk (be consistent) on the fly. I'd think you could keep fragmentation |> manageable by using the FFS; and by compressing in pages, you can still |> do random seeks through the file and change a little data in the middle |> without having to uncompress/recompress the whole file. I'd imagine memory mapped io on hash tabes to be a real nightmare. |> As an alternative, there could be a new type of executable file that |> incorporates compression, and the loader would uncompress it as it |> executed it. This would work well for less-seldom-used, non-persistent |> executables. What is the difference between an executable and a non-executable ? BTW the three least often used (i.e. opened for execution) files are /386bsd, /sbin/init and /sbin/fsck I'm sure you agree you wouldn't want them compressed... Note: I think the idea of an optional compressing filesystem is OK, I just see more potential problems than possible benefits. BTW - has anybody out there got a SunOs UFS filesystem for 386bsd ? -Bernard