Re: Hot-replace for RAID5
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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