NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 3 of 10)

NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 3 of 10)

Post by TIM RUNIO » Mon, 29 Jul 1996 04:00:00

do you know how to get to chat froums??

Dave Burgess wrote:

> Posted-By: auto-faq
> Archive-name: 386bsd-faq/part3

> Section 2.      (Common installation questions)

> 2.0     Install process

>         Once the files are on floppies, thoughts usually turn to
>         questions about how to install the boot image on a floppy.  The
>         rawrite program (for DOS) is used to write the bootable images
>         (dist.fs and fixit.fs) onto floppies.  The same image can used
>         for 3 1/2 and 5 1/4 high density diskettes. NetBSD uses the .fs
>         file extension for its floppy images.  FreeBSD uses the .flp
>         extension.

>         Once the bootable images are written onto the floppies, insert
>         the dist.fs disk into the A: drive and reboot.  If the system
>         does not boot, see section 2.5 below for more information.

>         If the disk boots, type install and proceed to use the
>         INSTALL.NOTES to get more information.

>         Problems with the install are either related to hardware (i.e.
>         Do you want to install on your T.V.?) or software.  Of the
>         hardware issues, the most common FAQs are usually straight out
>         of the installation notes.  Of the software issues, there are
>         only two that really concern us.  The first is bad files.

>         On some systems, files that are loaded from floppy appear to
>         'go bad' when they arrive on the hard disk.  Try some of these
>         solutions:

>         - You forgot binary.  Don't get insulted.  Those of us that FTP
>         for a living forget sometimes.  If so, the distribution will
>         come out with all different sizes and install will complain
>         about every disk.

>         - One or two of the files are no good.  Try getting them again.
>         As a precaution, rename the bad files on your hard drive to
>         names like foo.1 and bob.23.  Copy the files again from floppy.
>         If they are still bad, rename the file, and the one immediately
>         before the first bad file (bin01.23 if bin01.24 is bad) and
>         copy them again.  If they are still bad, download those files
>         again from the distribution site (including the one before and
>         after the bad one) and try again.

>         The reason for renaming the files is that sometimes, especially
>         with drive that do not auto-magically record bad sectors, you
>         could copy a distribution file onto a bad spot on the disk.  If
>         this happens, you want to isolate the bad spot.  The easiest way
>         to do that is just leave the bad file on it.

>         For those of you that have received your system on a CD-ROM,
>         you will need to find at least three things.  One is this file.
>         Since you are reading it, I assume that you got it already. :-)
>         If you can't read this file (you got it from the newsgroup, for
>         example) there is one thing that you need to know so you don't
>         look like a complete idiot on the net.

>         There is no such thing as a Unix CD-ROM.  They are all in
>         something called the ISO CD-ROM format.  You can read them as
>         the D: drive in DOS, or mount them on your Sun or SVR4 system
>         or whatever.

>         Second, you will need to find the directory with the bootable
>         disk images in it.  They will have self explanatory names like:

>         kerncopy.fs
>         base0-9.fs
>         fred.fs
>         genericaha.fs
>         boot-me-first.fs
>         this-is-the-file-with-the-fs-extension.fs

>         You get the idea, right?  Look for the MS-DOS program
>         "RAWRITE.EXE".  It should be right near the file system (.fs)
>         files.  Another clue for the truly lost will be that the file
>         system files will all be 1.2 Meg big.  These files will fit
>         onto either a 1.2Meg 5.25 inch diskette, or a 1.44Meg 2.5 inch
>         diskette.  Use rawrite to write the fs files to diskettes and
>         boot from the diskettes.

>         The FreeBSD system uses a system 'pretty much' the same as this,
>         except that the filesystem files are 1.2 Meg files and they all
>         have a '.flp' extension.  Other than that, the instructions
>         apply.

>         You did back your system up, right?

> 2.0.1   Boot disks  (versions and media formats)

>         When installing NetBSD, the set_tmp_dir and extract programs are
>         part of the .profile that is booted when you are installing.
>         This .profile is overwritten as part of the install process, and
>         extract then disappears.  If you need extract again, you can mount
>         the install disk and source .profile.  This will recreate these
>         two routines.

>         There is also an install procedure that FreeBSD uses that does
>         the same job.  It is defined as part of the .profile on one of the
>         installation floppies.  You can either copy it from there, or use
>         the procedure for 'real disk partitioning'.

>        The floppy booted, but now the hard disk won't boot?
>        I am trying to reinstall.  I run install and it loops
>                   asking me if I want to use the whole disk?

>         The most likely culprit is your hard disk controller.  If you
>         have an IDE or EIDE controller, it is probably doing some type
>         of disk translation for you.  If this is the case (assume it
>         is) then you will need to find out the real disk controller
>         geometry, and rewrite your disk label.  See section 2.6.2, but
>         before doing that get the program pfdisk.exe.  This program
>         will tell you what the controller geometry is (right before
>         it reboots your computer).  Make the disklabel agree with
>         this program and your system should boot.  You may have to
>         reinstall, but at least your disklabel will be right.  Note
>         that this is a nearly required step for all NetBSD and
>         FreeBSD installs.  You need to know what the disk geometry
>         is before the BIOS messes with it.  If you start having these
>         kinds of installation problems, I can virtually assure you that
>         it is because your controller geometry and your disklabel
>         geometry are different.

>         NOTE:  If the hard disk controller does NOT have an option for
>         turning off the geometry, you may well be completely out of
>         luck.  There are very few controllers that fall into this
>         category.  The ones that do full time translation will often
>         boot up in translated mode.  pfdisk will help you determine the
>         correct geometry for your drive by telling you what the geometry
>         looks like when 386bsd boots up.

>         But on the other hand, maybe not...

>         See section 2.5.5 below for a detailed set of instructions about
>         getting NetBSD (and by implication 386BSD and FreeBSD) to work with
>         a system that uses full time translation.

> What are the options on the boot prompt?

>         The most amazing thing about the boot process in *BSD is the
>         boot up alternatives that are available.  There is little that
>         a person can NOT do from the boot prompt.  The boot diskette or
>         disk can be selected (fd(1,a) for fd1a (my B: drive is DOS))
>         can be the source of my kernel.  In addition, the name of the
>         kernel can be chosen (this allows you to boot with a test
>         kernel or reboot an older kernel if the new one gets hosed).
>         Finally, there are three choices for options that may or may
>         not work, depending on the age and proclivities of your boot
>         blocks.  These options are documented in 2.5.9 below.

> I just used the '-s' option on the boot, but I can't write
>         anything onto the disk.  What is wrong?  If I use a plain 'mount'
>         command it tells me that my root file system is read-only.

>         In single-user (system booted with -s or an error in one of
>         the processes started by /etc/rc) the root filesystem mounts
>         as read-only by default. This was intended so that some range
>         of problems would not be made worse by writes to the disk.

>         The 'dos' partitions mount as read-only in that there are
>         reservations as to how well some of the FreeBSD tools work with
>         the pcfs.  The same kind of reservations exist with NetBSD and
>         the '-t msdosfs' option.  These options (-r for read-only, -w
>         for read-write) can be set in /etc/fstab.

>         The status of both can be changed with 'mount -wu /{mount.dir}'
>         (where {mount-dir} is the name of the directory that the
>         offending partition is mounted) to read-write.  Particularly for
>         the dos filesystem, the man page for mount should be read in
>         detail and the 'noexec' option examined.

>         Note that mounting the file systems using the '-a' option will
>         mount all of the file systems that are normally mounted with
>         their usual read-write bits set normally.  Using this option
>         makes your root partition writable, and also mounts the rest of
>         the partitions in your /etc/fstab that are normally mounted
>         during boot-up.

> 2.0.2   Fix-it boot disk

>         The fix-it disk contains a series of programs that are
>         particularly handy for 'fixing' your disk in case you can't get
>         logged in.  It includes the disklabel program and other utilities
>         for system maintenance.

>         For NetBSD and FreeBSD, you will probably have to build your own
>         Fixit disk.  You can mount the original file system floppy and
>         beat it to death if you want.  Put programs on it that you will
>         need to build a new system.  As I think of them, I will put them
>         in.

> 2.1     Binary distribution
> 2.1.1   I want to install by NFS but I am having all kinds of problems.

>         There is an unusual problem when installing over NFS.  This
>         solution may have been corrected in the documentation that comes
>         with FreeBSD and NetBSD, but if not, here it is.

>         The most common problem seems to be that FreeBSD (and by
>         inference NetBSD and all the other 4.4 based systems) do not
>         send out NFS requests over privileged ports.  Sun's NFS
>         implementation (and others, once again by inference) expect
>         precisely the opposite.  These systems will quietly fail if you
>         try to NFS to them.

>         The usual error message (which may ONLY appear in
>         /var/adm/messages) is "nfs_server: weak authentication, source
>         IP address=xx.xx.xx.xx"

>         SunOS is particularly insidious at this point.  The mount
>         succeeds, but then everything else after that fails.  This means
>         that your FreeBSD or NetBSD system will return ann EACCESS error
>         whenever you try to grab a file from the NFS filesystem.  The
>         solution (tested in FreeBSD) is to include the 'resvport' flag
>         like this:

>         # mount -o resvport server:/fs /mnt_point

>         or to use the -P flag (which does the same thing).  See the
>         mount and mount_nfs man pages for the details.

>         In fact, the -P flag provides a solution to the FreeBSD NFS
>         installation problem.  When prompted for server/filesystem, type
>         in the flag before the server/filesystem pair:

>           -P server:/fs

>         If you are using an 8-bit network card, and want to avoid the
>         ring buffer overflow problems that seem to come standard with
>         this class of cards, you can also include the "-r4096 -w4096"
>         flags between the -P and the server.

> 2.2     Configuration

>         By far, the most common configuration questions are partitioning,
>         followed closely by all of the other software in the system.
>         Sendmail and named are also problems occasionally, but the
>         documentation that comes with them usually gets you through.  If
>         you run into a problem, post a question to comp.os.386bsd.questions.

>         A less frequently asked question is "Where can I get info on how
>         to configure a kernel?"  The answer to this question has been
>         provided by Richard Murphey (Email address

>         --------------------------------------------------------------------
>         Ready-to-print PostScript files for each section of the net2 system
>         maintainer's manual are on in
>         pub/386bsd/submissions/bsd.manuals.

> describes kernel configuration for the VAX,
>         however some of it is relevant to 386BSD.  There is no freely
>         available rewrite for 386BSD that I know of.
>         --------------------------------------------------------------------

>         Most of these manuals are now included in the standard release of
>         NetBSD and FreeBSD in the /usr/share/doc directories.

> 2.5.1   Partitions

>         This section describes many of the questions that people ask about
>         hard disk partitioning.

>         The first is a brief explanation of the BSD system disk partitions.

> What is a 'disklabel' and why do I need one?

>         The BSD partition table supplements the DOS partition table.  The
>         entries in this table are meaningful to BSD.  There are eight
>         partitions in the BSD partition table, and they are normally
>         lettered from a: to h:.  This supplemental partition table is
>         often refered to as the 'disklabel'.

>         There have been many good articles in both the mailing lists and
>         the newsgroups about disk labeling and partitioning.  I have
>         included a few of them here.  NOTE:  This information has not
>         really changed since 386BSD 0.1.  Some of the specifics may be
>         out of date (the use of the d: partition, for example) but the
>         steps and information are still pertinent.

>         Phil Nelson ( writes:
>         I have installed several disks that have > 1024 cylinders and
>         have used both DOS and NetBSD.  What has worked for me EVERY TIME
>         is the following:

>         a) Tell the BIOS that you have 1023 cylinders and the correct
>         geometry for heads and sectors.  (This will limit your DOS part
>         of the disk to be LESS than the first 1023 cylinders.) You need
>         to have ALL of  your partition A (/dev/wd?a) in the first 1023
>         cylinders so that the boot program can read the kernel from
>         the root partition using the BIOS routines.  (ed note: You can
>         specify the full number of cylinders in some BIOSes and it won't
>         make any difference.  The DOS part of the disk will always be less
>         than 1023 cylinders.)

>         b) With fdisk, partition your 1023 cylinders as you want them.

>         c) Use the real geometry in NetBSD.  Once the NetBSD kernel is
>         booted, it does not have the 1024 cylinder limit: that is only
>         for the BIOS.  NetBSD only looks at the BSD disklabel, not the
>         DOS disk label.  The two disk labels (DOS and BSD) may not agree
>         on the BSD partition size!  This isn't a problem, since each
>         system's idea of the disks geometry is based on different
>         information.

>         d) Use NetBSD!

>         Chris Jones writes:

>         I was getting different reports of disk geometry from different
>         programs, so I opened up the computer and read the plastic label
>         on programs, so I opened up the computer and read the plastic
>         label on programs, so I opened up the computer and read the
>         plastic label on the drive.  I then instructed the BIOS (which,
>         when using auto-detect disagreed) what the disk geometry was.
>         Then, I used pfdisk to create partitions.  The first thing I did
>         with it was to tell it what the geometry really was.  It said
>         something about a symbolic mapping and dealt with it.  Then I
>         was able to specify all partitions in real units instead of
>         virtual ones.  NetBSD boots fine, and if memory serves, it is
>         the only program that has recognized the real disk geometry from
>         the beginning.

>         This tutorial is provided by by "<>" and
>         provides an  excellent overview of the hard disk partitioning
>         procedure from start to finish.

>                 "Disk Partitioning for the Compleat Idiot"

>         There are times, in our trials with our computers, that it becomes
>         necessary to mess about with the disklabel. For those not
>         knowledgeable of BSD or Unix Systems administration, this somewhat
>         simple task can be somewhat daunting. This document is the result of
>         my own short experience.

>         This does not cover physical installation of the disk. For those who
>         are having trouble with that, I direct you to any of the fine manuals
>         dealing with hard drives and your hardware.

>         It also does not deal with the vagaries of the DOS partition manager.
>         It assumes you have done that as well, if need be...

>         After the drive is physically installed and is recognized in the BSD
>         startup, and it mentions both your drives, in the order you expect
>         them... Or perhaps just the one, if you had special problems with
>         installation. Now all you have to do is "disklabel" the drive... Well,
>         what is *THAT*???

>         The disklabel is used by the kernel and other utilities to tell how
>         you want or have the drive set up *logically*.

>         In a beautiful world, we might have a very free hand at this set-up
>         and expect it to work. Unfortunately, the authors of the software
>         dealing with the hard drives either decided or were forced by
>         circumstance to make certain things about the disklabel inviolate.

>         When you let the installation disk set the disklabel for you first
>         drive it comes out like this:

>             The a: partition is the primary partition.
>             The b: partition is the swap partition.
>             The c: partition is the amount of the disk used by 386bsd
>                 (swap and data)
>             The d: partition is the entire disk (on the PC version only).

>         Of these, the only one that could be different is a:...

>         (Note for those of us who have spent far too much time using DOS: the
>         labels a: b: c: d: e: f: g: h: DO NOT refer to DOS drives, but to
>         partitions in your 386bsd partition... confusing, eh?  For the sake
>         of consistency I will never make a reference to DOS drives except by
>         saying something like "DOS drive C:". )

>         It's possible to divide up the disk a bit differently, but three
>         things MUST be:

>         c: must refer to every cylinder you wish 386bsd to use, either
>         for your data or the swap space.

>         d: Must refer to the whole disk, from cylinder 0 to the last
>         one...

>         b: Must always refer to a swap partition. Note that on any
>         other than the first disk it does not have to, but if you
>         enable swapping on that drive, and you are using b: for
>         something else, that something else will be killed.

>         The reason for this is simple: It's hard coded in.

>         "WHY?" you ask? (I did...) Probably time constraints, maybe tradition.
>         But if you look at the code in "isofs" and "ufs" in your sys.386bsd
>         directory, you will see numerous comments asking some of the same
>         questions, which leads me to believe this may change in the future,
>         making our lives both more complicated and easier at the same time...

>         Getting past the esoteric explanations, here is a method for figuring
>         out and "labeling" your disk.

>         We'll start with the disklabel from my second disk, in the form most
>         understandable by humans... #'s signify the start of a comment.

>         # /dev/rwd1d:
>         type: ESDI
>         disk: maxtor7245
>         label:
>         flags:
>         bytes/sector: 512
>         sectors/track: 31
>         tracks/cylinder: 16
>         sectors/cylinder: 496
>         cylinders: 967
>         rpm: 3600
>         interleave: 1
>         trackskew: 0
>         cylinderskew: 0
>         headswitch: 0           # milliseconds
>         track-to-track seek: 0  # milliseconds
>         drivedata: 0

>         5 partitions:
>         #      size  offset  fstype [fsize bsize   cpg]
>         a:   198400       0  4.2BSD    512  4096    16  # (Cyl.    0 - 399)
>         b:    31744  447392    swap                     # (Cyl.  902 - 965)
>         c:   479136       0  unused      0     0        # (Cyl.    0 - 965)
>         d:   479136       0  unused      0     0        # (Cyl.    0 - 965)
>         e:   248992  198400  4.2BSD    512  4096    16  # (Cyl.  400 - 901)

>         Some math:
>         Looking at the comments at the end and the size and offset columns,
>         size is a function of (last - first + 1) * sectors per cylinder:
>         a: 399 - 0 + 1 = 400 * 496 = 198400
>         b: 965 - 902 + 1 = 64 * 496 = 31744
>         c: & d: (Since I have no DOS partition, whatsoever)
>            965 - 0 + 1 = 966 * 496 = 479136
>         e: 901 - 400 + 1= 502 * 496 = 248992

>         248992 + 198400 + 31744 = 479136 (all the parts should equal the whole)

>         Some things I discovered  (for all you in novice land like me...)

>         1. As you can see this disk has 967 cylinders, but I only refer to 966
>         of them, 0 - 965... This is because it's good practice to leave the
>         "Landing Zone" cylinder out of it... This is usually the last
>         cylinder, and it's where the read/write heads hang out when your disk
>         is off...

>         Note from TSgt Dave:

>         Most modern drive heads come to rest on a polished surface inside the
>         highest cylinder.  I could be mistaken, of course, and the Hard Drive
>         Bible (or other appropriate reference manual) will tell the tale for
>         each drive.

>         2. a: can be a regular partition, b: should be swap, c: everything
>         386bsd will get to use, including swap. d: is the entire disk from
>         0 - (cylinder_per_disk - 2)   [leaving out the Landing Zone]

>         On the boot drive (The drive that actually contains the kernel), a:
>         is the boot partition.  On all other drives, it is a regular partition.
>         Reagardless of whether you are using DOS or not, the entire a:
>         partition must reside completely within the first 1024 sectors.
>         This is a limitation of the PC architecture.

>         You can then use e - h for your other partitions. I am not sure
>         whether you could specify b: as other than a swap partition and not
>         run into trouble, but you could surely make it a zero sized one
>         starting and stopping on the Landing Zone...

>         Note from TSgt Dave:

>         This is a good idea.  Another way to accomplish this is to
>         simply not specify it in the map.

>         3. Stupid human trick: When doing the math don't forget that 400 - 900
>         refers to 50*1* cylinders. I did, for a while. No great problem I
>         suspect, but why waste a cylinder...

>         4. newfs'ing really is that simple if you have the label right:
>         "newfs /dev/rwd?x config_template" where the question mark is the
>         physical disk, the x is a partition letter, and the config_template
>         is the configuration from /etc/disktab for your disk drive.

>         * NOTE:  This is a thumbnail sketch; read the man page to verify all
>         of the options and be sure about how to proceed...

>         5. then fsck the partition:
>         fsck /dev/rwd?x

>         Don't forget that fsck should be run on the RAW device.

>         6. As long as it checks out, you can then mount it and do disk things
>         with it...

>         7. Add it to the fstab... (follow the man page).  Don't forget
>         that your new swap partition won't work if your kernel isn't
>         configured for it, but it won't cause you any problem to have
>         it there.

>         One last note from TSgt Dave:

>         And I have yet to figure out a way to determine if it is or
>         isn't using the swap partition anyway.  There is a program called
>         'swapinfo' and it is part of the NetBSD source tree.  On my system,
>         it tells me that I never use the swap area. :)

>         Comnonly used definitions:

>         bsize:
>         Block Size:  This is the smallest allocatable area on a disk file
>         system, sort of.  A file uses the maximum amount of blocks until it
>         can not completely fill up a block.

>         fsize:
>         Fragment Size:  This is the size of the 'leftover' data that didn't
>         fit into a full block.  For example, assuming a using an 8K Block
>         Size/1K Fragment Size, a 34.5K file, would use up 4-8K Blocks (4 *
>         8K = 32K) and 3 1K fragments (3 * 1K = 3K).  There is 512 bytes of
>         wasted space, since 32K + 3K = 35K, which is 512 bytes larger than
>         34.5K.  If you want to reduce the amount of wasted space, you can
>         reduce your fragment size, but you also reduce the amount of data
>         you read at one time, so your disk performance decreases also.
>         A good setup is 8K/1K for performance, but if you are really
>         concerned about wasted space you can consider using a 4K/512byte
>         filesystem.

>         For further information, find an article that explains the Berkeley
>         FFS in more detail.

>         cpg:
>         Cylinders Per Group, it determines the cylinder group size, which
>         in turn determines the number and location of the alternate
>         superblocks.

>         Cgd posted a description of how to manually install 386bsd and
>         create 'real' BSD partitions.  It is excerpted below:

>         --------------------------------------------------------------------

>         (remember, if things don't work, they might be in places that aren't
>         normally looked in... things should work as below, but you might
>         have to use explicit paths occasionally... the 'better' stuff --
>         mount, umount, cp, etc... is in /usr/distbin on the fixit floppy...
>         even mknod is there, if the devices you need aren't on the fixit
>         floppy...)

>         (1) boot the fixit floppy
>         (2) disklabel the disk as appropriate
>         (3) newfs the partitions
>         (4) mount the new root partition under /mnt
>         (5) mkdir /mnt/usr
>         (6) mount the new /usr partition under /mnt/usr

>         (7) cpio the entire contents of the fixit floppy to the hard drive
>                 cd /
>                 ls .profile * [0-ln-z]*/* */*/* | cpio -pdalmu /mnt
>                 (NOTE: [0-ln-z]*/* is to avoid matching mnt/mnt)
>         (8) copy /usr/distbin/mount and /usr/distbin/umount to /mnt (so that
>                 they'll be in the new root partition, so you can mount the
>                 new /usr partition...)
>         (9) shutdown
>                 and the eject the floppy.
>         (10) reboot off the hard drive, then fsck -p <root raw device>
>                 If there are any errors, after the fsck is done, hit
>                 ctl-alt-delete, and repeat this step.
>         (11) fsck -p <usr raw device>
>         (12) mount -u <root device> /
>         (13) mount <usr device> /usr
>         (14) insert 0.1 boot/install floppy (dist.fs) into floppy drive
>                 and "mount /dev/fd0a /mnt"
>         (15) cd /mnt
>                 and then
>                 usr/bin/zcat etc/baselist.Z | usr/bin/cpio -pdalmu /
>         (16) cd /
>                 and then
>         /mnt/usr/bin/zcat /mnt/etc/baseutils.cpio.Z | /mnt/usr/bin/cpio -idalmu
>         (17) umount /mnt        then eject the floppy
>         (18) umount /usr
>         (19) shutdown
>         (20) reboot off the hard drive, and get all of the various files (the
>                 bindist files, srcdist files, etc...).
>                 I put them into /usr/tmp, because there wasn't enough space
>                 in /tmp (because it was on a small root partition...).
>         (21) cd / ; cat <all the binary files> | uncompress | cpio -idalmu
>         (22) rm <all the binary files>
>         (23) put your hostname into "/etc/myname" and put your ip addr/hostname
>                 into /etc/hosts.
>         (24) make an fstab for yourself.  specifically, you want something like:
>                 <root device name>      /       ufs rw 1 1
>                 <usr device name>       /usr    ufs rw 1 2

>         congratulations!  you now have a working system!

>         you can repeat step 21 for the srcdist and etcdist files, as well,
>         if you wish...

> What other kinds of information do I need if I really want to
>         tune my hard drive's performance in conjunction with a newfs?

>         Having taken Kim's suggestion and changed my newfs values, I
>         think I've now made some empirical observations that suggest
>         that the defaults for newfs should definitely be changed.

>         With all the disks I tested with, -n 1 (which isn't even
>         *documented!*) provided greatly improved performance, as
>         opposed to all other values of -n.  I think that with
>         sector-addressed drives with complex physical geometries,
>         rotational position optimization is a technique which is no
>         longer valid.

>         If _anyone_ has _any_ disk larger than 300MB or so (or even
>         a small disk) manufactured within the last few years for which
>         larger values of -n produce better performance than -n 1, I'm
>         very curious to hear about it.  I'd be particularly interested
>         in any disk for which the default value produces optimal results.

>         Increasing maxcontig seemed to always improve write scores, but
>         values of maxcontig above 16 seemed to have a noticeable _negative_
>         impact on read performance.  -a 512, for example, on the disk in
>         my machine at home, yielded a peak write rate (4MB file, 8K record
>         size) of 4.7MB/s, much better than the 4.3MB/s value for -a 64,
>         but read performance was reduced from 2.6MB/s to 2.1MB/s.  I do
>         not understand why this is the case, and I'd love suggestions.

>         I believe that with rotational position optimization turned
>         off (-n 1), the value of the -r option is of no consequence.  I
>         believe that the fact that with the default value for -n, the
>         -r option seemed to have little or no impact on performance
>         serves to demonstrate that rotational optimization does not
>         work correctly on modern drives.

>         The default value of the -d option also produces much worse
>         results than -d 0.  I'm probably inexact up above; I believe
>         that -n 1 -d 0 is what turns off rotational position optimization
>         entirely.  I'm all for it. :-)

>         I suggest that the defaults for newfs be changed to:

>             -n 1 -d 0 -a 16 -r 5400

>         The -r value just in case someone decides to try playing with
>         rotational position optimization for some incomprehensible
>         reason.  Though actually, anyone with a disk where said
>         optimization is a win might want -r 3600 after all.

>         If someone can explain why values of -a above 16 seem to
>         negatively impact read performance, I'm all for making -a very
>         very large, like 512 or 1024 -- in this case the filesystem
>         code will automatically limit maxcontig to the maximum transfer
>         size for a given controller/disk, right?  What are some typical
>         such sizes?  Why does -a 512 hurt read performance so much, and
>         how can it be fixed?  From comments by Larry McVoy, a good
>         implementation of UFS with clustering will yield disk speed
>         on writes, and about 25% less on reads.

>         Right now, on my hardware at least, we seem to _surpass_
>         slightly the speed of raw writes to the disk device on writes,
>         but on reads we lose big as the maxcontig value goes up, and we
>         seem to lose worst on large file/record sizes, where the raw
>         device delivers about 5MB/s in my case, but with -a 512 I get
>         only about 2.5MB/s under UFS.

>         If you can't guess, I'm incredibly curious as to why the value
>         of -a affects reads as much as it does, or at all, for that matter.

>         Still, we don't do so