[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