Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!gargoyle!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Compressing unix disks
Message-ID: <11096@mimsy.UUCP>
Date: 16 Apr 88 07:24:02 GMT
References: <6139@cit-vax.Caltech.Edu> <548@eos.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52

>In article <6139@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu
>(Don Speck) writes:
>>I've heard over and over that the Berkeley Fast Filesystem is considered a
>>CPU hog.  So I tried a trivial experiment....  BSD beat SysV in system
>>time, even though SysV was running on a CPU twice as fast and optimized
>>for SysV!  So why does everybody claim that the BSD filesystem is a CPU hog?

In article <548@eos.UUCP> jaw@eos.UUCP (James A. Woods) answers:
>the rumor probably started at murray hill, where they don't look too
>kindly on complicated filesystem code.

Actually, I remember a Berkeley paper---probably the original fast file
system paper---that claimed that the 4.2BSD file system was designed
with faster processors in mind; this might lead to such a claim.  The
4.3BSD `/usr/doc/smm/14.fastfs' paper (which those who do not
understand the 10% free space reserve are encouraged to PLEASE GO READ
NOW AND STOP BLATHERING AND ... sorry, I got carried away :-) ) notes
that

    The overhead of allocating blocks in the new system is greater
    than the overhead of allocating blocks in the old system,
    however fewer blocks need to be allocated in the new system
    because they are bigger.
    The net effect is that the cost per byte allocated is about
    the same for both systems.

>the payoff with the berkeley filesystem is too large to ignore, as
>tests against sys5 repeatedly show.

I have never done the tests, but given the difference between the
4.2BSD FFS and the old 4.1BSD FS, if the SV FS is much like the 4.1BSD
FS (which, I gather, it is), I would have to agree.  Writes are at
least no more common than reads, and since `the cost per byte allocated
is about the same' one has nothing to lose anyway, except perhaps the
need for fsdb.

>some say the advantages theoretically disappear in a multi-user environment
>where seeks are scheduled randomly, but i've never seen the degradation
>in real life.

I think I have, but so rarely that it matters not.  95%* of the time
you win by 85%*, so you are 80% ahead already, or something along those
lines.  Especially it does not hurt that backups take half the time
they consumed under 4.1BSD.  [*These numbers were calculated by that
time-honoured method, Choosing Numbers that Sound Good Based on Nothing
at All.  Your mileage may vary, moreso in California and where
prohibited by law or customs officials.  (The author of this article is
suffering from Chocolate Overdose and an overly loud rendition of
`Where's the Walrus?' from the _Stereotomy_ CD, if you were wondering.)]
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris