MSCP for you and me

Doug Alan nessus at athena.mit.edu
Wed Oct 26 10:01:34 AEST 1988


Thanks to Chris Torek and Michael Bushnell for helping with some
problems I have had with the BSD4.3 MSCP disk driver.

>> If you accidentally attempt to boot a system on a
>> disk drive for which there is no partition table in the kernal, BSD
>> kindly trashes the filesystem for you.

> [Chris Torek:] The 4.3BSD UDA50 driver treats unknown disks as type
> `ra81'.  I considered this bogus [...]

This could defintely explain why my root filesystem got trashed if I
had a bigger-than-normal root filesystem.  But I always make my root
filesystems be no bigger than 15884 sectors to prevent exactly this
sort of disaster....

>> I also have a more academic question: A BSD filesystem is supposed
>> to begin on a cylinder boundary for performance reasons.  Is swap
>> space also supposed to begin a cylinder boundary, or does it make no
>> difference?  I know there's "tunefs", and there's tuna fish, but
>> there's no "tuneswap"....

> It hardly matters, but if everything else starts and ends on a
> cylinder boundary, the free region(s) left over for swap space will
> do so as well.

Ah, but since I keep my root partitions down at 15884 sectors, the
root partition doesn't end on a cylinder boundary.  Right now I start
my swap space (on an XT8760) at 16380, instead of 15884, so that it
will begin on a cylinder boundary.  I haven't lost a whole lot of
sleep over it, but I have wondered on occasion, whether there really
is any advantage at all in wasting those 496 sectors....

I have another question for BSD disk driver wizards: I discovered
sometime recently that if I use "tunefs" to change "maxcontig" for a
filesystem from 1 to 2, the read performance of the filesystem (for a
single process) increases about 25%.  Increasing the setting to 3 did
not result in any increase in performance, so I left it at 2.  (We use
8K blocks.)

The man page for "tunefs" says you should only increase "maxcontig" on
a device driver that can chain several buffers together in a single
transfer.  Can the MSCP device driver do this?  Is there any reason
why I shouldn't leave "maxcontig" set to 2.  My rough benchmarks were
only for a single process.  Does anyone think this might degrade
system performance.  Another issue is that our disk controllers are
smart, and you can set them to prefetch blocks (the controller also
does caching -- prefetched blocks go into the cache).  Setting the
prefetch to be 32 sectors (2 blocks) also resulted in another little
increase in filesystem read performance for a single process.

|>oug /\lan

   (or nessus at athena.mit.edu
       nessus at mit-eddie.uucp)



More information about the Comp.unix.wizards mailing list