Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!nessus From: nessus@athena.mit.edu (Doug Alan) Newsgroups: comp.unix.wizards Subject: MSCP for you and me Message-ID: <10337@eddie.MIT.EDU> Date: 26 Oct 88 00:01:34 GMT Sender: uucp@eddie.MIT.EDU Reply-To: Doug Alan Organization: Kate Bush and Butthole Surfers Fandom Center Lines: 54 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@athena.mit.edu nessus@mit-eddie.uucp)