Re: mdadm bad blocks list

[NeilBrown <nfbrown@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

On Thu, Jan 28 2016, Sarah Newman wrote:

> I experienced the following problems with the mdadm bad blocks list:
>
> 1. Additions to the bad block list do not cause an email to be sent by the mdadm monitor. Expected behavior is for an email to be sent as soon as the
> bad blocks list becomes non-empty.

Yes, that would be a good idea.  If you do develop patches, please post
them.

> 2. /proc/mdstat does not show any indication that there are bad blocks present on an md member. Specifically, the status for the raid personality
> should show something other than "U" if the badblocks list is not empty for that member (maybe "B"?)

I'd like to deprecate /proc/mdstat.  It is not really easy to extend.
People might have programs that parse it which could break if you change
'U' to 'B'.
I'd recommend using "mdadm" to get status of an array, or examine file
in /sys.

> 3. Adding a device when there is an md member with bad blocks does not appear to trigger a rebuild, meaning there could be at least one good copy of
> all the data but no way to get all good data on a single device without expanding the entire array.

Good point.  That would be quite easy to change.  Just set
WantReplacement if the bad block list is ever empty.
Not sure it is always a good idea though.  You can have a bad block on a
perfectly good device if the device it was recovered from has a bad
block.
You only really want to set WantReplacement automatically if a write
fails.  We do do that, but if you stop and restart an array the fact
that a write failed can be forgotten.

>
> Kernel: CentOS 6 Xen4CentOS 3.18.21-17
> mdadm: CentOS 6 v3.3.2
>
> With the above behavior, I consider the bad blocks list to be actively harmful. If it's expected behavior in the current version, please consider
> disabling the bad blocks list by default.

You can do this yourself by putting

  CREATE bbl=no

in /etc/mdadm.conf.  That doesn't help others though.

I'm not convinced that it is harmful, though I accept that it is not perfect.

>  We might be able to provide some patches to correct 1. and 2. but we don't have anything ready right now.

That would be great if you could.
Thanks for your thoughts.

NeilBrown

>
> --Sarah
> --
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]