(I accidentally sent my first reply directly to the OP, and forgot the
mailing list - I'm adding it back now, because I don't want the OP to
follow my advice until others have confirmed or corrected it!)
On 09/05/2012 21:53, Patrik Horník wrote:
> Great suggestion, thanks.
>
> So I guess steps with exact parameters should be:
> 1, add spare S to RAID5 array
> 2, mdadm --grow /dev/mdX --level 6 --raid-devices N+1 --layout=preserve
> 3, remove faulty drive and add replacement, let it synchronize
> 4, possibly remove added spare S
> 5, mdadm --grow /dev/mdX --level 5 --raid-devices N
Yes, that's what I was thinking. You are missing "2b - let it synchronise".
Of course, another possibility is that if you have the space in the
system for another drive, you may want to convert to a full raid6 for
the future. That way you have the extra safety built-in in advance.
But that will definitely lead to a re-shape.
>
> My questions:
> - Are you sure steps 3, 4 and 5 would not cause reshaping?
I /believe/ it will avoid a reshape, but I can't say I'm sure. This is
stuff that I only know about in theory, and have not tried in practice.
>
> - My array has now left-symmetric layout, so after migration to RAID6
> it should be left-symmetric-6. Is RAID6 working without problem in
> degraded mode with this layout, no matter which one or two drives are
> missing?
>
The layout will not affect the redundancy or the features of the raid -
it will only (slightly) affect the speed of some operations.
> - What happens in step 5 and how long does it take? (If it is without
> reshaping, it should only upgrade superblocks and thats it.)
That is my understanding.
>
> - What happens if I dont remove spare S before migration back to
> RAID5? Will the array be reshaped and which drive will it make into
> spare? (If step 5 is instantaneous, there is no reason for that. But
> if it takes time, it is probably safer.)
>
I /think/ that the extra disk will turn into a hot spare. But I am
getting out of my depth here - it all depends on how the disks get
numbered and how that affects the layout, and I don't know the details here.
> So all and alll, what guys do you think is more reliable now, new
> hot-replace or these steps?
I too am very curious to hear opinions. Hot-replace will certainly be
much simpler and faster than these sorts of re-shaping - it's exactly
the sort of situation the feature was designed for. But I don't know if
it is considered stable and well-tested, or "bleeding edge".
mvh.,
David
>
> Thanks.
>
> Patrik
>
> On Wed, May 9, 2012 at 8:09 AM, David Brown<david.brown@xxxxxxxxxxxx>
wrote:
>> On 08/05/12 11:10, Patrik Horník wrote:
>>>
>>> Hello guys,
>>>
>>> I need to replace drive in big production RAID5 array and I am
>>> thinking about using new hot-replace feature added in kernel 3.3.
>>>
>>> Does someone have experience with it on big RAID5 arrays? Mine is 7 *
>>> 1.5 TB. What do you think about its status / stability / reliability?
>>> Do you recommend it on production data?
>>>
>>> Thanks.
>>>
>>
>> If you don't want to play with the "bleeding edge" features, you
could add
>> the disk and extend the array to RAID6, then remove the old drive. I
think
>> if you want to do it all without doing any re-shapes, however, then
you'd
>> need a third drive (the extra drive could easily be an external USB
disk if
>> needed - it will only be used for writing, and not for reading unless
>> there's another disk failure). Start by adding the extra drive as a hot
>> spare, then re-shape your raid5 to raid6 in raid5+extra parity
layout. Then
>> fail and remove the old drive. Put the new drive into the box and
add it as
>> a hot spare. It should automatically take its place in the raid5,
replacing
>> the old one. Once it has been rebuilt, you can fail and remove the
extra
>> drive, then re-shape back to raid5.
>>
>> If things go horribly wrong, the external drive gives you your parity
>> protection.
>>
>> Of course, don't follow this plan until others here have commented
on it,
>> and either corrected or approved it.
>>
>> And make sure you have a good backup no matter what you decide to do.
>>
>> mvh.,
>>
>> David
>>
>
>
--
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
