Hi Christoph, Thank you for the review. > On Jul 26, 2020, at 8:10 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Fri, Jul 24, 2020 at 09:33:22AM -0700, Ritika Srivastava wrote: >> If WRITE_ZERO/WRITE_SAME operation is not supported by the storage, >> blk_cloned_rq_check_limits() will return -EIO which will cause >> device-mapper to fail the paths. >> >> Instead, if the queue limit is set to 0, return BLK_STS_NOTSUPP. >> BLK_STS_NOTSUPP will be ignored by device-mapper and will not fail the >> paths. > > How do we end up calling blk_cloned_rq_check_limits when the operations > aren't actually supported? The upper layers should make sure this never > happens, so you're just fixing symptoms here and not the root cause. The device advertises it’s write zero value as non zero value: cat /sys/block/sdh/queue/write_zeroes_max_bytes 33553920 Hence block layer issues write zeroes in blkdev_issue_zeroout() In response, the storage returns the following SCSI error Sense Key : Illegal Request [current] Add. Sense: Invalid command operation code Once this error is received, the write zero capability of the device is disabled and write_zeroes_max_bytes is set to 0. DM device queue limits are also set to 0 and device-mapper fails the path. To avoid this, if BLK_STS_NOTSUPP could be returned, then device-mapper would not fail the paths. Once the write zero capability has been disabled, blk-lib issues zeroes via __blkdev_issue_zero_pages(). Please let me know if I missed something.
