> On Jun 23, 2015, at 4:12 PM, Phil Turmel <philip@xxxxxxxxxx> wrote:
>
> Hi Jared,
>
> On 06/23/2015 02:56 PM, Jared Mauch wrote:
>> I’ve been searching high and low the past few days and have been unable to diagnose what this (R) is in my raid1 mdstat output indicates.
>
> Replacement device.
Yeah, I inferred that from the device role below, but I also wanted
something that google would index well for others to confirm.
>> It seems something is ‘stuck’ somehow as I’m not sure how the array is both clean and degraded at the same time.
>
> Role '0', currently sdd1, is being replaced with sdg1. Both appear to
> be working as expected and are therefore individually 'clean'. Role '1'
> is missing, and therefore the array as a whole is degraded.
>
> Looks to me like you lost a device and should have used --add to put a
> new device into service, but you used --replace instead. --replace is
> for use when a functioning device shows signs of failing and is to be
> replaced 'on-the-fly’.
I’ve tried doing a few things including repair to see what it will do
but when it completes it’s in the same end-state.
> [trim /]
>
>> Device Role : Replacement device 0
>> Array State : R. ('A' == active, '.' == missing, 'R' == replacing)
>
> However, the array doesn't seem to be making progress on the replacement
> (didn't even start ?), so this pathological situation might have
> triggered a bug in the resync code.
Let me know what debugging/details might be interesting to collect.
Based on the Events# being in-sync, I am going to assume that the drives
may be operating in a protected-type mode even if the output doesn’t
concur.
I can say this state seems to survive reboots.
- Jared--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
