Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: System V file systems
Keywords: System V
Message-ID: <14152@mimsy.UUCP>
Date: 25 Oct 88 21:49:24 GMT
References: <6413@daver.UUCP> <8332@alice.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

In article <8332@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes:
>Given a fast CPU, a not-very-intelligent disk controller and the optimal
>interleaving and file system gapsize, the performance is roughly linearly
>proportional to the block-size. ...

Block size is a large, and probably the largest, factor in actual I/O
performance on real Unix machines.  The BSD Fast File System's cylinder
group arrangement does have a non-negligible effect on at least one
thing, however: backups speed up by more than the ratio of block sizes
when switching from a V7/4.1BSD/SysV style file system.  Faster seeks
make the effect of cylinder groups less dramatic, but we still have
a number of old washtub drives in service (until they fail and would
be expensive to fix, as none are under service anymore).

>The main reason why block-size is the limiting factor is that both the
>OS and the disk-controller have only slightly more work handling an 8k
>block than a 1k block. So you don't hit the hardware speed-limit as soon
>with larger block-sizes.

It would help if the disk drivers were clever, and coalesced adjacent
block requests and/or read whole tracks at a time.  (A Fuji Eagle with
48 sectors/track is 3 4.3BSD 8K blocks, and with `-a 3' files might
be contiguous across one track often enough to make this worthwhile.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris