Subject: Re: Disk performance under NetBSD on A3000
To: Stephen Champion <firstname.lastname@example.org>
From: Michael L. Hitch <email@example.com>
Date: 04/24/1995 08:15:04
On Apr 24, 2:50am, Stephen Champion wrote:
> Michael L. Hitch said:
> > A question for both Stephen and Arthur - what is the rotational
> > delay between contiguous blocks for your file system? I tried dd
> > on an older partition (and a slower disk) and got 455902 bytes/sec.
> > After using tunefs to set the rotational delay to 0, I got 1048576
> > bytes/sec. [The old default for newfs was 4ms for the rotational
> > delay - which is not a good default for current SCSI drives.]
> I am experiencing poor disk performance under NetBSD as well.
> I've thought about using tunefs but am unsure of how to find a good
> rotational delay. Is 0 a good value for faster drives (ie Quantum LPS
> and/or Quantum Empire)? How should the rotdelay be calculated, anyway?
> It would be nice if the tunefs (8) man page included such information.
The rotational delay is used by the file system to determine where to
place the next 'maxcontig' segment of a file after the previous segment.
This is [was] to give time for the kernel to process the data from one
read and eliminate the need to wait for the disk to complete a full
revolution to read the next consecutive block(s) from the disk. This
was designed for the much older disk technology that did not have any
cache or read-ahead capability, and probably slower rotational speeds.
Almost (if not all) current SCSI disks should have an internal cache
that does read-ahead, so as far as NetBSD is concerned, there is
effectively no rotational delay needed. Having a non-zero value could
even eliminate or severely reduce the read-ahead of the SCSI drive: the
SCSI drive would receive requests for non-contiguous blocks and could
possibly cause the current read-ahead to be flushed an a new one
started. It depends a lot on how the read cache algorithm is designed
in the SCSI controller.
To determine a value for older disks, you would need to determine how
much time it might take NetBSD between reads of consecutive blocks on
the disk. The setting of maxcontig in the file system also has a
bearing on this. I think the default is currently 8. For an older
disk, the maxcontig could possible be set up to the number of blocks
used by the filesystem blocksize [8K or 16 blocks is the default
filesystem blocksize] - providing the disk system is able to read
multiple blocks efficiently. I would think almost all SCSI disks should
be able to read multiple blocks without impacting the performance.
Michael L. Hitch INTERNET: firstname.lastname@example.org
Office of Systems and Computing Services
Montana State University Bozeman, MT USA