(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
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".
> On Wed, May 9, 2012 at 8:09 AM, David Brown<david.brown@xxxxxxxxxxxx>
>> 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?
>> If you don't want to play with the "bleeding edge" features, you
>> the disk and extend the array to RAID6, then remove the old drive. I
>> if you want to do it all without doing any re-shapes, however, then
>> need a third drive (the extra drive could easily be an external USB
>> 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
>> 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,
>> the old one. Once it has been rebuilt, you can fail and remove the
>> drive, then re-shape back to raid5.
>> If things go horribly wrong, the external drive gives you your parity
>> Of course, don't follow this plan until others here have commented
>> and either corrected or approved it.
>> And make sure you have a good backup no matter what you decide to do.
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