I did not get a clear reply, and decided to follow my assumption that the 128MB header is used lightly (only 4K-16KB seem to be non zero). I just cleared the bad block dd of=/dev/sdi1 bs=4K seek=32456 count=1 if=/dev/zero The write was successful and no bad blocks were recorded in smart log. Everything else looks good, and hopefully the next 'check' will stay clean too. The general question remains, at least some conformation of the how much space is actually used in the header. Maybe add this to 'mdadm -E'? cheers Eyal On 02/26/14 19:16, Eyal Lebedinsky wrote:
In another thread I investigated an issue with a pending sector, which now seems to be a bad sector inside the md header (the first 256k sectors). The question now remaining: what is the correct approach to fixing this problem? The more general issue is what to do when any md control area develops an error. does all data have redundant copies? The simple way that I see is to fail the member, remove it, clear it (at least --zero-superblock and write to the bad sector) and then add it. However this will incur a full resync (about 10 hours). Is there a faster, yet safe way? I was thinking that a clean umount and raid stop should allow a create with --assume-clean (which will write to the bad sector and "fix" it), but the doco discourages this. Also, it is not impossible to think that the specific bad sector (toward the end of the header) is not actually used today, meaning I can live with it as is, or write anything to the bad sector as it does not get used. Too involved though. A bad sector in the data area should be fixed with a standard raid 'check' action. TIA
-- Eyal Lebedinsky (eyal@xxxxxxxxxxxxxx) -- 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
