Michael L. Hitch said:
> 
> On Apr 24,  2:50am, Stephen Champion wrote:
> > Michael L. Hitch said:
>   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.

	Indeed.  Before using tunefs to change the rotdel to 0, I was 
seeing 500k/s reads and 425k/s writes on my Quantum LPS and 700k/s reads 
and 500k/s writes on my Empire 1080S.  After changing rotdel to 0, I now 
have 1M/s write and 1.6M/s reads on the Empire, and the read time on the LPS 
increased to 700K/s.
	Interestingly, the times seem to be slightly better with a 64k 
blocksize than with a 1024k blocksize.

	This is the test I used:

echo "blocksize 1024k, count 10"
dd if=/dev/zero of=/dev/null bs=1024k count=16
sync
dd if=/dev/zero of=disktest bs=1024k count=16
sync
dd if=disktest of=/dev/null bs=1024k count=16
rm disktest
echo "blocksize 64k, count 256" 
dd if=/dev/zero of=/dev/null bs=64k count=256 
sync
dd if=/dev/zero of=disktest bs=64k count=256 
sync
dd if=disktest of=/dev/null bs=64k count=256 
rm disktest

	The memory transfer tests both reported 4.19M/s or 3.36M/s.
I ran the tests in multiuser on an A3000/25 + Retina Z2 + A2065 on an LP105S 
and EMP1080S connected to the internal SCSI controller.  AFAIK, there was 
no other disk access during the tests, although the results varied 
slightly in some cases.  DMA and syncronous transfers are enabled.

	Sysinfo reports 1.2M/s on the LPS and 3.5M/s on the EMP.  I 
haven't done any raw tests under NetBSD (won't writing to /dev/sd1c 
destroy the filesystem??).

	Thank you Michael, especially for the explanation!



	As I understand it, rotdel influences where on the disk data is written.
So, data written when the rotdel was 4 will not gain from the change.  Is 
there anything in out there (or in the standard distribution) that will 
realign the data already on the drive to benefit from the change, or do I 
need to back up, mkfs, and restore the file systems to affect the data 
already there?  I didn't see anythoing to this effect in the fsck or 
tunefs man pages, or their references.

-- 
//  Stephen Champion                   Software Eng, *ix Admin, OS Design
//  schampion@hampshire.edu            Hampshire College - Amherst, MA
//  steve@herb.kuru.com                Amiga 3000/25    NetBSD 1.0
#define Disclaimer "This product is completely without warranty."