On 28/07/2011 10:25, Lutz Vieweg wrote:
On 07/27/2011 10:55 PM, NeilBrown wrote:
[...]
On failure it decides not to write to and more bad blocks on that
device.
This sentence may just miss one verb, but that might be an important
one. Did you mean to say "on failure (of writing to a block that had
been marked as bad, after a re-assembly) that one block will not be
written to (until after the next re-assembly)"?
I think the typo was that he meant "any" where he wrote "and": "On
failure it decides not to write to any more bad blocks on that device".
So after a re-assembly (e.g. when you boot up after fixing your power,
cable, controller issues) md will try writing to bad blocks again, until
any such writes fail, after which it will stop trying to write to bad
blocks on that device. By this method, md can automatically recover from
spurious write failures caused by temporary issues.
Sorry I got it wrong in the first place, by the way - I'd seen the
writeable sysfs entries for manipulating the bad block list, so that's
why I thought there was an administrative interface for clearing it, but
if that's only there for md/mdadm's internal use and testing, we
ordinary users had better leave it alone :-)
Cheers,
John.
--
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
