Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin <piggin@cyberone.com.au>]

Chuck Ebbert wrote:

>Nick Piggin wrote:
>
>
>
>>OK right. As far as I can see, the algorithm in the RAID1 code
>>is used to select the best drive to read from? If that is the
>>case then I don't think it could make better decisions given
>>more knowledge.
>>
>
>
>  How about if it just asks the elevator whether or not a given read
>is a good fit with its current workload?  I saw in 2.5 where the balance
>code is looking at the number of pending requests and if it's zero then
>it sends it to that device.  Somehow I think something better than
>that could be done, anyway.
>
That balance code is probably the IDE or SCSI channel balancing?
In that case, the driver simply wants to know which device it
should service next, which is an appropriate fit (is that what
you were talking about? I don't have source here sorry)


We could ask the elevator if a given read is a good fit. It
would probably help.

>
>
>
>>It seems to me that a better way to layer it would be to have
>>the complex (ie deadline/AS/CFQ/etc) scheduler handling all
>>requests into the raid block device, then having a raid
>>scheduler distributing to the disks, and having the disks
>>run no scheduler (fifo).
>>
>
>
> That only works if RAID1 is working at the physical disk level (which
>it should be AFAIC but people want flexibility to mirror partitions.)
>
How so? Basically you want your high level scheduler to run first.
You want it to act on the stream of requests from the system, not
on the stream of requests to the device. If you know what I mean.

I might be wrong here. I haven't done any testing, and only a
little bit of thinking.

>
>
>
>>In practice the current scheme probably works OK, though I
>>wouldn't know due to lack of resources here :P
>>
>
>
> I've been playing with the 2.4 read balance code and have some
>improvements, but real gains need a new approach.
>
The problem I see, is the higher level schedulers (deadline for
example, as opposed to the RAID scheduler) will find it difficult
to tell if a request will be "good" for them or not. For example
we have 2 devices, 100 requests in each scheduler queue.

Device A's head is at sector x and next request is at x+100,
Device B's head is at sector x+10 and next request is at x+200.

RAID wants to know which queue should take a request at sector
x+1000. What do you do?

The way you would do a good "goodness" function, I guess,
would be to search through all requests on the device, and return
the minimum distance from the request you are running the query
on. Do this for both queues, and insert the request into the
queue with the smallest delta. I don't see much else doing any
good.

On the other hand, if you simply have a fifo after the RAID
scheduler, the RAID scheduler itself knows where each disk's
head will end up simply by tracking the value of the last
sector it has submitted to the device. It also has the advantage
that it doesn't have "high level" scheduling stuff below it
ie. request deadline handling, elevator scheme, etc.

This gives the RAID scheduler more information, without
taking any away from the high level scheduler AFAIKS.