Re: waiting for recovery to complete

[David Greaves <david@dgreaves.com>]

Hervé Eychenne wrote:
> On Sun, Apr 17, 2005 at 10:49:14AM -0700, Tim Moore wrote:
>>The recovery daemon adjusts reconstruction speed dynamically according to 
>>available system resources.
>>Disk I/O is somewhat slower but works just fine.  You don't have to wait.
> 
> 
> So I don't have to wait to take the disk out, as the recovery will
> continue with embedded disk battery and wireless bus connection?
> How cool... ;-)
Your original phrasing looked (to me too) like you thought you couldn't 
use the raid whilst it was reconstructing (I'm still not convinced you 
realise this so, to be clear: "whilst mdadm is rebuilding the array you 
can use the array as normal with no risk of data corruption. You do 
_not_ have to wait for resync to finish before remounting and using the 
device.")
Tim's response told you you had no need to be alerted when it was OK 
since you had no need to stop working in the first place.

(And why are you wanting to take a disk out after you just synced it? - 
no, don't answer that...)

Now it looks like you just want to know when it's done for your own 
peace of mind, so...
> 
> Well... more seriously, I can't believe this question doesn't raise
> any interest, even if it seems like it does not. :-(
well, once recovery has started I don't *really* care when it finishes.
> Does everyone really type cat /proc/mdstat from time to time??
> How clumsy...
And yes, I do :)
(well, actually I optimise to <up arrow> <return>)

> I just want to chat about the best way to add a backend for this kind
> of feature, so we could implement that properly... (and yes, that is
> definitely _nedded_ if you want to do things right)
If you want to monitor _properly_ then use nagios (or monit)

Or since mdadm already uses -F to follow and notify on errors, then I 
suggest you start hacking other alert options in there...

David

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html