Are we forced to use bad blocks list?

Dear MD developers,
it seems that with mdadm 3.3.1 , if an array has bad blocks disabled (e.g. "--update=no-bbl" was invoked) and we want to add a disk to that array, e.g. a spare, that one will be created by mdadm with BBL enabled during the --add operation.

There is apparently no "--add --no-bbl" option in mdadm, so the BBL will result in being forcibly active for that disk, it seems to me.

It is indeed possible to "--stop" the array and then "--assemble --update=no-bbl" so to clear the BBL flag in all disks, but this requires stopping the array, which for a production system often is not possible, and not justified for just adding a spare.

Can I add a "feature request" to have BBL optional, and/or to default BBL presence/absence so that it conforms to the presence/absence of BBLs in the other disks of the array which is already running?

The same problem probably happens when mdadm monitor daemon moves spares among the spare-group: it should probably understand if the receiving array is configured for BBL or not, and add a spare of the same type.

Quoted 5 lines · On Thu, 31 Jul 2014 16:31:28 +0200 Ethan Wilson<[email protected]>…

Dear MD developers,
it seems that with mdadm 3.3.1 , if an array has bad blocks disabled
....
array is configured for BBL or not, and add a spare of the same type.

Why don't you want bad-block-lists?

I'm not necessarily against having some why to avoid getting them automatically ... possibly a 'policy' option in mdadm.conf. But I'd like to make sure I understand all of your thinking first.

Thanks,
NeilBrown

Quoted 8 lines · NeilBrown

Quoted 5 lines · On Thu, 31 Jul 2014 16:31:28 +0200 Ethan Wilson<[email protected]>…

Dear MD developers,
it seems that with mdadm 3.3.1 , if an array has bad blocks disabled
....
array is configured for BBL or not, and add a spare of the same type.

Quoted 8 lines

Why don't you want bad-block-lists?

I'm not necessarily against having some why to avoid getting them automatically ... possibly a 'policy' option in mdadm.conf. But I'd like to make sure I understand all of your thinking first.

Thanks,
NeilBrown

Hello Neil,

Well... on the ML, I think that we saw the badblocks code triggered only once, and it was with the recent thread of Pedro Teixeira.

It seemed to me that his error condition could indicate that there might be a bug in the bad blocks code. It's not clear to me how those zillions of bad sectors could have been stored without some bug such as an erroneous propagation of bad blocks, or erroneous handling or degraded mode (he said he operated with a doubly degraded raid6 after 3 disks dropped out).

Additionally, when he did fsck, that should have cleared the bad blocks which were being written over, but he said that
"When doing a fsck.ext4 of /dev/md0 it returns the following ( and I can do it over and over again with the exact same errors) ..... " I think 'exact same errors' is not supposed to happen if I understand the intent of BBL correctly.

So, I can't be sure, but I have the feeling it's possible that there are still a few bugs in the BBL code. MD RAID in general is very stable and I really like it so much, but maybe on production systems I'd keep the BBL disabled still for a while, if possible.