Re: Hot-replace for RAID5

[David Brown <david.brown@hesbynett.no>]

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