Subject: Re: NCR Driver Problems
To: None <>
From: Brad Walker <>
List: current-users
Date: 01/24/1996 23:06:39
> From owner-current-users@NetBSD.ORG Wed Jan 24 22:35 PST 1996
> Date: 24 Jan 1996 22:23 +0100
> From: (Christoph Badura)
> To: current-users@NetBSD.ORG
> Subject: Re: NCR Driver Problems
> Kridle, R., and McKusick, M., "Performance Effects of Disk Subsystem
> Choices for VAX Systems Running 4.2BSD UNIX", CSRG, Dept of EECS, UCB
> technical report #8, 1983
> >And it is worth mentioning that this is paper is
> >most likely quite a few years old. Before current technology.
> I don't think someone has invented a way for disk controller firmware
> to divine the optimal execution order of requests in the last 13
> years.

I don't mean to be nitpicking and I'm certainly not interested
is starting an e-mail war. And I don't mean anything person by

But, doesn't it seem that 1983 is a little out-dated in terms of
technology? There is current technology that can re-order the execution
of command so as to optimize actuator head seeks. Also, this doesn't
necessaryly have to do with disks either. You might have a big disk
farm with slow storage and lots of ram. The files migrate between the
ram and slow storage depending on use. There is a company in
Massachusetts that does this. Tagged-commands would be perfect for

And disksort() can break down when one has things where the disk drive
geometry is changes depending on where the head is positioned. For
example, disksort() has an idea about a virtual drive geometry. But
comtemporary SCSI drives use something called Zone Bit Recording. This
means that the outer cylinders have more sectors on them. So now what
you have is a situation where the OS's virtual idea of the disk is
different from reality where tracks can have variable number of sectors
on them.

Hope this cleared up what I was thinking when I wrote my last e-mail.

-brad w.