Re: Bogus entry in mdadm bad blocks list and question about particular commit

[Sarah Newman <srn@prgmr.com>]

On 02/02/2016 12:46 PM, Jes Sorensen wrote:
> Sarah Newman <srn@prgmr.com> writes:
>> I added some more drives to a raid 1 last night where some devices had existing bad block entries. There was nothing of particular interest in
>> /var/log/messages. Afterwards there is:
>>
>> $ sudo /sbin/mdadm --examine-badblocks /dev/sdl1
>> Bad-blocks on /dev/sdl1:
>>    11986270392325491 for 51 sectors
>>
>> The total number of sectors on the drive is 3907029168.
>>
>> The start sector in the bad blocks list is 2a95730cea9573 in hex, I don't know if that string has any special significance or not.

>> I looked for differences in between 3.18.21 and stable 3.18.y and the
>> only interesting thing looked like e9206476ace "md/raid1:
>> submit_bio_wait() returns 0 on success". I don't think that's a
>> smoking gun for the bogus bad blocks entry. But without that commit,
>> mdadm with bad blocks enabled is completely broken if there are write
>> errors such that successful writes are reported as errors and vice
>> versa, is that correct?
> 
> Sarah,
> 
> If I remember correctly, yes then badblocks handling was pretty wedged
> without that patch since it broke the narrowing down of the problem. If
> you have to run such an old kernel, you really ought to backport
> 681ab4696062f5aa939c9e04d058732306a97176 and
> 203d27b0226a05202438ddb39ef0ef1acb14a759 if you have raid1 and/or raid10
> arrays.

Noted.

What about the bad blocks entry with the completely bogus sector, is there a plausible explanation for that?

Thanks, Sarah