tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Raidframe and disk strategy



Thor Lancelot Simon <tls%panix.com@localhost> writes:

> 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.

I see that as "if you don't only use the disk for rf, it's not going to
work so well" and conclude "diskstrategy isn't good enough" rather than
"don't do that" (although I won't argue it's currently a good idea).


>>   - 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.

I was thinking about how things ought to be, so indeed I was ignoring
that.

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

I know you know this, but "better" is wicked complicated, and it's some
combination of overall efficiency and fairness/timeliness to different
request queues.  Given that, I wonder what the justification is for rf
doing any sorting/prioritizing.

> 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.

But that leaves out half the disk in RAID-1 and half not.  Why can't we
just have rf not sort and have each disk sort?

> 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.

So that's where I ended up.  I am unclear on the benefit of having a
strategy above rf, but also cannot conclude that it is unreasonable or
unuseful.

Do we currently have queueing at the rf layer?  Or does an operation get
translated into lower-level operations without blocking the next one's
translation?

> 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.

Currently, but it seems to be that if one process asks for 1000 io ops
per second and one for 2 per second, and the drive can do 200, then
probably the 2/s process should get its data faster.  That's perhaps not
supported by any current strategies, but I think it's important not to
preclude it.  But that means process tags need to be passed through rf
to the underlying strategy.

Attachment: pgpwx76nP3RL2.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index