Re: Hot-replace for RAID5

(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[off-list ref]  wrote:

quoted

On 08/05/12 11:10, Patrik Horník wrote:

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html