Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!eos!jaw
From: jaw@eos.UUCP (James A. Woods)
Newsgroups: comp.unix.wizards
Subject: Re: Compressing unix disks
Message-ID: <548@eos.UUCP>
Date: 15 Apr 88 20:43:42 GMT
References: <6139@cit-vax.Caltech.Edu>
Organization: NASA Ames Research Center, California
Lines: 40

From article <6139@cit-vax.Caltech.Edu>, by mangler@cit-vax.Caltech.Edu (Don Speck):
> In article <7582@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
>> you seem to need CPU to use the Berkeley FFS, and System V is popular on the
>> little *nix boxes.
> 
> I've heard over and over that the Berkeley Fast Filesystem is considered a
> CPU hog.  So I tried a trivial experiment, a program that does 512 writes
> of 8K bytes each (enough to exceed the buffer cache) and the times were:
> 
> 3B20S SysV.2,  1K fs blocksize	    32.6 real  0.0 user  11.4 sys
> vax-750 4.3BSD 8K fs blocksize	     8.5 real  0.0 user   8.2 sys
> 
> 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?
> 
> Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck

the rumor probably started at murray hill, where they don't look too
kindly on complicated filesystem code.  but the payoff with the berkeley 
filesystem is too large to ignore, as tests against sys5 repeatedly
show.  it'd be interesting to see stats comparing the edition nine
4k block system with the 4.3 one on the same machines, but i don't
know how weinberger handles the horrendous small-file wastage
addressed by mckusick's fancy block/fragment code.  sure berkeley
wastes 10% of the disk (does someone now have a cure for this?),
but throwing away 45% by just using large blocks with no fragment scheme
would be disaster.

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.

ironically, the small boxes need the performance boost just as much --
witness the apple mac2 50k byte/sec fiasco.  any machine that can't
load a megabyte of ascii in a second or two requires coding contortions
for basic word-processing at hand/eye reflex speed.
and small machines generally don't run multi-user, so the other random seek
myth wouldn't even apply.

so again, why do vendors deal with the system5 filesystem at all?