[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: changing raid level?
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
> 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.
Main Index |
Thread Index |