*BSD News Article 19227


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