by do you know how to get to chat froums??
> Posted-By: auto-faq 3.1.1.2
> 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'.
> 2.0.1.2a The floppy booted, but now the hard disk won't boot?
> 2.0.1.2b 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.
> 2.0.1.4 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.
> 2.0.1.5 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 r...@Rice.edu).
> --------------------------------------------------------------------
> Ready-to-print PostScript files for each section of the net2 system
> maintainer's manual are on nova.cc.purdue.edu in
> pub/386bsd/submissions/bsd.manuals.
> smm.02.config.ps.Z 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.
> 2.5.1.1 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 (p...@cs.wwu.edu) 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 "<ha...@husc.harvard.edu>" 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:
> --------------------------------------------------------------------
> HOW TO GET 386bsd 0.1 INSTALLED WITH "REAL" PARTITIONING:
> (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...
> 2.2.1.2 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