Re: Raidframe and disk strategy

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Thu, Aug 09, 2012 at 08:40:51AM -0400, Greg Troxel wrote:
> 
> Thor Lancelot Simon <tls%panix.com@localhost> writes:
> 
> > RAIDframe implements its own disk sorting algorithm (several, actually)
> > internally.  Why sort twice?
> 
> I don't follow this.
> 
>   - RAIDframe might not be the only user of the physical disk

It should be -- at least the only user generating a significant
stream of requests -- or RAIDframe itself should use its FCFS
sorting strategy and let the underlying disk device driver sort.
I consider it PEBKAC if it's not.

>   - without thinking too much, it seems that the normal strategies
>     should be used to sort requests to RAIDframe, and also the normal
>     strategies to sort requests made by RAIDframe to the physical
>     disks.  Perhaps the latter should do fairshare between raid and
>     other, and keep raid in order.

You're ignoring the fact that RAIDframe itself sorts internally.  So that
would make a total of three sorts.

Complicating matters slightly is that we know priocscan is better than
any of RAIDframe's sorting algorithms, for a wide variety of workloads.

The intent, one assumes, is to have an ordered stream of requests
at the disk.  It doesn't matter whether they're ordered when they
hit RAIDframe or not, and RAIDframe itself sorts them into whatever
order you tell it to before outputting them.  So the ideal situation,
it seems to me, would be priocscan sorting inside RAIDframe and
no sorting either above or below it.

Failing that, RAIDframe should do FCFS, and, it seems to me, in
theory at least, you want to sort the resulting request stream below
it (closer to the disk).  It's not clear to me what the benefit would
be from sorting above it.

There would seem to be some worry about losing the queue "priorities"
that drive the priocscan algorithm, but really those are just determined
by whether a request is read or write, so that problem, at least, should
not exist.

Thor