I was able to fix the volume and the filesystem!

  - the command Neil posted didn't work but I got the idea and made a  
script that cleared the list for all disks. The --examine-bad-blocks  
still lists the bad blocks, and stopping and assembling the volume  
again will populate the bad block list again. Still, I cleared them  
all again and issued a "repair" on the volume. I got a bunch of errors  
from a couple of disks, mostly sdk and sdb but the volume synced till  
the end, and after stopping it and assembling it again, no bad blocks  
in any disk, and --examine-bad-blocks also showed no bad blocks. I  
have since replaced sdk and sdb, with no errors when syncing and no  
errors on dmesg. After that I fsck'd the filesystem, and it's up and  
running again. I will now replace the other two disks that exibited  
read errors when repairing the volume as soon as I get some  
replacements.

Thanks all for the help!!!

As a sugestion, I would make md distinguish a read error that is  
caused by no good strip available due to bad block list from other  
read errors to ease troubleshooting and maybe implement a way to clear  
bad block list from disks with mdadm ( and maybe forcing a resync of  
that strip after the list is cleared ).


Cheers
Pedro

________________________________________________________________________________
Mensagem enviada através do email grátis AEIOU
http://www.aeiou.pt
--
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