[NCLUG] sw raid, recovery after install

Michael Milligan milli at acmeps.com
Wed Jan 16 19:27:24 MST 2013


On 01/16/2013 05:42 PM, Stephen Warren wrote:
> On 01/16/2013 05:30 PM, Michael Milligan wrote:
>> On 01/16/2013 04:36 PM, Stephen Warren wrote:
>>> On 01/16/2013 04:07 PM, Michael Milligan wrote:
>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/mdcfg/+bug/77470
>>>
>>> Ugggh. I sincerely hope that never gets fixed, or e.g. RAID-1 array
>>> scrubbing never has a chance of finding that the mirrors are in sync...
>>
>> But who cares
> 
> Well, obviously me:-)

Then do this after the install is done to force a sync:

echo "repair" > /sys/block/[array]/md/sync_action

... and then go work on something else productive.  ;-)

> If the two drives aren't initially and always exact mirrors of
> each-other, the scrubbing process will always say that the arrays
> mismatch. That makes the scrubbing process basically useless. Running

Yup.

> the scrubbing process and making sure the two drives don't start to
> mismatch is a good RAID monitoring tool. See /usr/share/mdadm/checkarray.

Yup.  Caveat being though that by the time you have a RAID mismatch,
you've exhausted the drive (or drives!) bad-block remapping capability
and are now teetering on the precipice of disaster.  S.M.A.R.T.
monitoring is a better tool to watch for drives going bad.

I just avoid the checkarray nonsense by using ZFS these days.  Works
/great/ on FreeBSD (but that's off-topic).

I /wish/ I could use BTRFS for a modern file system on Linux, but it
turned into such a pile of s__t that I had to give up on it and move on
to something else (which ended up being ZFS on Linux).  After the second
time an entire dataset is irrecoverably lost on a BTRFS filesystem,
well, you tend to chuck that crap out the window.  ;-)

Regards,
Mike




More information about the NCLUG mailing list