System V file systems

[Chris Torek]

>In article <Oct.25.22.42.50.1988.1890 at geneva.rutgers.edu>
>hedrick at geneva.rutgers.edu (Charles Hedrick) notes that
>>... The BSD file system is designed to avoid fragmentation [of the
free list, eventually resulting in blocks being allocated `at random'].
>>Of course this problem will not show if you do your tests right after
>>creating the file system.

In article <1988Oct27.173247.2789 at utzoo.uucp> henry at 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.  If you read
>the fine print, all the Berkeley performance tests were run single-user!!
>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.

I actually agree with this (in spite of the point others have noted as
to the weak definition of `time shared').  But it is important to
consider several things.  Not the least is that workstations (e.g.,
Suns) are virtually single-user.  Certainly there are servers and
daemons running, and you may be multiprocessing, but `on the average'
you tend not to have more than one process doing file system I/O.
Second, read-ahead blocks are moved into the buffer cache at the same
time as the block actually being read; if these are adjacent, the r.a.
block will come in more or less immediately, even if the disk then has
to move the heads elsewhere for someone else's page-outs.  So you get
`two for the price of one', as it were.  Also---and to us, this is not
the least important point---often, when the machine really *is* in
single user mode, you will want file reading to be as fast as possible,
so that your backups will finish soon and you can allow the next batch
of news to flow in.  The BSD FFS allocation policies do a fair job of
keeping files straight even in the presence of multiprocessed/timeshared
writes.

In other words, while I think that the large blocks are the most
important factor, I am not unhappy about all the rest of it.  (After
all, *I* did not have to write the code . . . :-) ---and I have not had
to do much to `maintain' it, either; Kirk did a good job of the code
[think that is a hint, Mike? :-) ])
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris