Re: RAID-10 keeps aborting

["H. Peter Anvin" <hpa@zytor.com>]

On 06/03/2013 10:22 AM, Dan Williams wrote:
> On Mon, Jun 3, 2013 at 8:47 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 06/02/2013 11:14 PM, Dan Williams wrote:
>>>
>>> If I'm reading things correctly that may still result in failure since
>>> md will still pass the REQ_WRITE_SAME bios down to the the devices and
>>> will receive BLK_PREP_KILL for its trouble.  md only notices that
>>> write same is disabled on underlying devices at assembly time.
>>>
>>
>> I have to admit to not seeing where md (as opposed to dm) even looks for
>> if the underlying devices have write same enabled.  It seems extremely
>> likely that it is write same that is causing the headaches, though.
>>
> 
> raid10 calls disk_stack_limits() after blk_queue_max_write_same_sectors().
> 

OK, I see it now.

I wonder changing blk_queue_max_write_same_sectors() to zero in the
kernel sources would do the trick here... might be easier than making
udev/dracut to the right thing... :-/

> ...and here is where scsi considers failures as non-fatal in
> sd_done().  I assume the REQ_QUIET is why there are no other kernel
> messages.

>                         case WRITE_SAME_16:
>                         case WRITE_SAME:
>                                 if (unmap)
>                                         sd_config_discard(sdkp, SD_LBP_DISABLE);
>                                 else {
>                                         sdkp->device->no_write_same = 1;
>                                         sd_config_write_same(sdkp);
> 
>                                         good_bytes = 0;
>                                         req->__data_len = blk_rq_bytes(req);
>                                         req->cmd_flags |= REQ_QUIET;
>                                 }
>                         }
>                 }
>                 break;

OK, so the device here says don't do this again, but fails the request
anyway expecting the block device to pick up the slack.

	-hpa