tech-kern archive

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

Re: Raidframe and disk strategy



On Wed, 8 Aug 2012 15:07:24 -0700
buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow) wrote:

>       hello.  I've been looking at some disk performance issues
> lately and trying to figure out if there's anything I can do to make
> it better.  (This is under NetBSD/I386 5.1_stable with sources from
> July 18 2012).  During the course of my investigations, I discovered
> the raidframe driver does not implement the DIOCSSTRATEGY or
> DIOCGSTRATEGY ioctls.  Even more interestingly, I notice its set to
> use the fcfs strategy, and has been doing so since at least
> NetBSD-2.0.  The ccd(4) driver does the same thing. Presumably, the
> underlying disks can use what ever strategy they use for handling
> queued data, but I'm wondering if there is a particular reason the
> fcfs strategy was chosen for the raidframe driver as opposed to
> letting the system administrator pick the strategy?  My particular
> environment has a lot of unrelated reads and writes going on
> simultaneously, and it occurrs to me that using a different disk
> strategy than fcfs might mitigate some of these issues.  Were bench
> marks done to pick the best strategy for raidframe and/or ccd or is
> there some other eason I'm missing that implementing a buffer queue
> strategy on top of these devices is a bad idea? -thanks -Brian

The "FIFO" strategy was the one that seemed to be the best tested at
the time, and since I didn't want to introduce any more variables,
that's the one I went with as a default.  Unfortunately, the RAID
labels currently don't specify the queuing strategy, so the
'autoconfig' sets won't do anything other than FIFO at this time.
Non-autoconfig sets certainly support any of the other queuing
methods in the config file, and that could certainly be used for
testing/benchmarking.

If you'd like to write up support for alternate queuing methods being
specified by the component labels let me know -- it'd be one less thing
on my TODO list :) 

Later...

Greg Oster


Home | Main Index | Thread Index | Old Index