On 06/03/2013 10:22 AM, Dan Williams wrote:
> On Mon, Jun 3, 2013 at 8:47 AM, H. Peter Anvin <hpa@xxxxxxxxx> 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
--
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
