System V file systems

[Charles Hedrick]

>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. 

Two problems: 

(1) To get really good performance, you have to use a block size so
large that you waste lots of disk space on small files.  The BSD file
system can split the last block in a file into fragments. You get the
benefits of a big block size on all but the last block, and don't
waste the disk space.

(2) System V (at least SVr2, and I think also SVr3) uses a free list,
which it does not keep in order, so an active file system fragments
very soon.  The BSD file system is designed to avoid fragmentation.
Of course this problem will not show if you do your tests right after
creating the file system.

The BSD fast file system is more than just larger block sizes.  It
makes sense for SVr4 to support both the old and new, to allow people
to move between SVr3 and SVr4 during testing and conversion.  However
once you have committed to SVr4, I'd think you would want to move to
the fast file system.