Re: changing raid level?

[Greg Oster <oster%cs.usask.ca@localhost>]

Eric Haszlakiewicz writes:
> On Wed, Jan 28, 2009 at 08:26:12AM -0600, Greg Oster wrote:
> > Manuel Bouyer writes:
> > > On Tue, Jan 27, 2009 at 01:23:37PM -0600, Greg Oster wrote:
> > > >   [...]
> > > > 
> > > > For a RAID 1 set, the "parity unit" is simply the second disk, and 
> > > > computing that parity requires no further computations.
> > > 
> > > On a slow CPU the read+read+compare+write is killing the whole system
> > > (mostly the "compare" I think) with 90% of the cpu working on this.
> > > A simple read+write is much, much better on such a setup (the system
> > > is still useable while doing a raid1 reconstruct). It matters
> > > even on a fast CPU, when both disks are able to provide data at 180MB/s.
> > > The system is still useable but comptationnal tasks (esp. network
> > > encryption) is much, much slower.
> > 
> > What should happen here is that RAIDframe should have a tweakable 
> > sysctl knob (or something) to adjust the rebuild rate.  It's on the 
> > TODO list, but has never reached any sort of priority level where 
> > it's gotten done :(  
> 
> Or, perhaps it could measure the reconstruction speed and switch to whichever
>  one goes faster, while throttling to ensure X% cpu available for other tasks.

That's nice in theory, but I don't even want to think about the work 
required to switch to whichever one is faster :-}  (The amount of 
stuff done to make sure no-one is accessing a stripe while it's 
rebuilding, and what parts of the disk to use if reconstruction 
hasn't reached that point yet is non-trivial...  The code goes to a 
fair bit of effort to make sure things are done right, and one would 
need to be very careful not to break that, or any of the assumptions 
being made.)

> I guess the X would still end up being sysctl knob anyway, but you
>  wouldn't need to tweak it b/c you're on a slower (or faster) machine.

Right...

Later...

Greg Oster