Re: problem killing raid 5

[Daniel Santos <daniel.dlds@gmail.com>]

All the drives are identical, and they are on identical usb enclosures. 
I am starting to suspect USB. It frequently resets the enclosures. I'll 
have to look at that first. Anyway I had it working before for some time.

Justin Piszcz wrote:
>
>
> On Mon, 1 Oct 2007, Daniel Santos wrote:
>
>> It stopped the reconstruction process and the output of /proc/mdstat 
>> was :
>>
>> oraculo:/home/dlsa# cat /proc/mdstat
>> Personalities : [raid6] [raid5] [raid4] [raid1] [raid0] [linear]
>> md0 : active raid5 sdc1[3](S) sdb1[4](F) sdd1[0]
>>     781417472 blocks level 5, 256k chunk, algorithm 2 [3/1] [U__]
>>
>> I then stopped the array and tried to assemble it with a scan :
>>
>> oraculo:/home/dlsa# mdadm --assemble --scan
>> mdadm: /dev/md0 assembled from 1 drive and 1 spare - not enough to 
>> start the array.
>> oraculo:/home/dlsa# cat /proc/mdstat
>> Personalities : [raid6] [raid5] [raid4] [raid1] [raid0] [linear]
>> md0 : inactive sdd1[0](S) sdc1[3](S) sdb1[1](S)
>>     1172126208 blocks
>>
>> The fourth drive I had to put in mdadm.conf as missing.
>>
>> The result was that because of the read error, the reconstruction 
>> process for the new array aborted, and the assemble came up with an 
>> array that seems like the one that failed before I created the new one.
>>
>> I am running debian with a 2.6.22 kernel.
>>
>>
>> Michael Tokarev wrote:
>>> Patrik Jonsson wrote:
>>>
>>>> Michael Tokarev wrote:
>>>>
>>> []
>>>
>>>>> But in any case, md should not stall - be it during reconstruction
>>>>> or not.  For this, I can't comment - to me it smells like a bug
>>>>> somewhere (md layer? error handling in driver? something else?)
>>>>> which should be found and fixed.  And for this, some more details
>>>>> are needed I guess -- kernel version is a start.
>>>>>
>>>> Really? It's my understanding that if md finds an unreadable block
>>>> during raid5 reconstruction, it has no option but to fail since the
>>>> information can't be reconstructed. When this happened to me, I had to
>>>>
>>>
>>> Yes indeed, it should fail, but not stuck as Daniel reported.
>>> Ie, it should either complete the work or fail, but not sleep
>>> somewhere in between.
>>>
>>> []
>>>
>>>> This is why it's important to run a weekly check so md can repair 
>>>> blocks
>>>> *before* a drive fails.
>>>>
>>>
>>> *nod*.
>>>
>>> /mjt
>>>
>>>
>>
>> -
>> 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
>>
>
> Yikes.  By the way are all those drives on the same chipset? What type 
> of drives did you use?
>
> Justin.
>