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