Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!esosun!ucsdhub!ucsd!ucbvax!bostic
From: bostic@ucbvax.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.unix.wizards
Subject: Re: System V file systems
Message-ID: <26599@ucbvax.BERKELEY.EDU>
Date: 28 Oct 88 17:20:18 GMT
Article-I.D.: ucbvax.26599
References: <6413@daver.UUCP> <8332@alice.UUCP> <1988Oct27.173247.2789@utzoo.uucp>
Organization: University of California at Berkeley
Lines: 19

In article <1988Oct27.173247.2789@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> Or if you run your tests in a time-sharing environment, where the disk
> heads are always on their way to somewhere else anyway.

This depends solely on your job mix; I recently saw figures someone derived
from trying to decide how best to queue requests for a new disk driver.  The
sampled system normally showed no head movement between the original request
and subsequent/read-ahead requests.  If you have a system with an
overloaded/limited number of disks, your paradigm is much more likely to be
correct.

> We conjectured a long time ago that the only feature of the 4.2 filesystem
> that matters much in a timesharing environment is the big block size; I
> haven't yet seen any solid results (numbers, not anecdotes) that would
> contradict this.

Given the nebulousness of the word "timesharing", I suspect you never will.

--keith