On Wed, 17 Oct 2012 12:50:44 -0700 buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
> hello. Thanks for the reply. I was just loking at the > raidframe code to determine if the queueing strategy was permanent > across reboots. Also, I apologize Edgar, cscan is not a valid > queueing strategy name. The four choices are: fifo, cvscan, sstf and > scan. > > As to the possibility of implementing persistent disk queuing > strategies, I was thinking that the easiest way might be just to add > an option to store the letter of the queuing strategy in the > component label, and then having the autoconfigure code set the > queueing strategy when it runs during the next reboot. You can > already achieve a change to the queuing strategy on a raid set by > unconfiguring it and reconfiguring it. (Yes, that means you have to > reboot for root raid sets or raid sets that can't be unmounted at run > time, but that seems safer than trying to do this change on the fly, > especially since it isn't something one would do often under most > circumstances.) Unconfiguring/reconfiguring is a pain... I think what we really need is an ioctl or similar to set the strategy (it can just pass in a config struct with only the strategy field set -- that mechanism is already there). The ioctl code can then do the quiesce/change/go song'n'dance and update component labels accordingly. New code in the component label code would read in the strategy (from a newly carved out field from the component labels) and away we go. There's lots of free space remaning in the component labels, and this change would be backwards compatible with older kernels. New kernels seeing a '0' in that spot would simply pick 'fifo' as before. One question is whether to use 0,1,2,3 to encode the strategy, or to use letters, or whatever. But that's just a minor implementation detail. > I've got a raid set that I use for backups that I've altered > to use the scan strategy. > > Thoughts? > -Brian Later... Greg Oster
