System V file systems

[Chris Torek]

In article <8332 at alice.UUCP> debra at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris