Re: Raidframe and disk strategy

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        hello.  Thanks for the quick reply.  My understanding is that the
disk drivers which implement selectable queueing algorithms, do so by
selecting the default strategy at boot time and then letting the user
select the strategy they want to use with the dkctl(8) utility by means of
the DIOCGSTRATEGY and DIOCSSETRATEGY ioctls.  I would propose doing the
same thing for the raidframe driver.  Right now, unless I'm seriously
missing something, it's not possible to change the disk strategy for any
raid device, whether its configured manually or with the autoconfigure
routines.  It's also not clear to me that there needs to be any changes to
the component labels to support this feature.  IN fact, unless the
administrator runs dkctl(8) against the raid device, the patches I'm
thinking of will cause raidframe to behave as it always has,just allowing
the administrator to change the queuing strategy as he can with wd or sd or
ld disks.
        I'll cook up a patch and send it out for people to fly with so that my
ramblings make more sense.
-thanks
-Brian

On Aug 8,  4:38pm, Greg Oster wrote:
} Subject: 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
>-- End of excerpt from Greg Oster