Re: [PATCH] scsi: sd: Use UNMAP in case the device doesn't support WRITE_SAME

[Bean Huo <huobean@gmail.com>]

On Wed, 2020-10-07 at 23:47 -0400, Martin K. Petersen wrote:
> > support WRITE_SAME. The problem is that WRITE SAME heuristics
> > doesn't work
> > for this kind of storage device since its block limits VPD page
> > doesn't
> > contain the LBP information. Currently we set its provisioning_mode
> > "writesame_16" and didn't check "no_write_same".
> 
> There is something odd with what your device is reporting.
> 
> We support WRITE SAME on a bunch of devices that predate the Logical
> Block Provisioning VPD page and the various Block Limits parameters
> being introduced to the spec. Consequently we set the provisioning
> mode
> to "writesame_16" if the device reports LBPME=1 in READ CAPACITY(16)
> and
> nothing relevant is reported in the VPD pages. That is by design.
> 
> > If we didn't manually change this default provisioning_mode to
> > "unmap"
> > through sysfs, provisioning_mode will be set to "disabled" after
> > the
> > first WRITE_SAME command with the following error occurs:
> 
> If your device supports UNMAP it *must* report it in the Logical
> Block
> Provisioning VPD by setting LBPU=1 and report MAXIMUM UNMAP LBA COUNT
> and MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT in the Block Limits VPD.
> 
> Also, "no_write_same" disables attempting to use WRITE SAME to zero
> block ranges. That's orthogonal to the logic controlling which
> command
> to use for performing an unmap operation. An unfortunate choice of
> naming which can be attributed to the SCSI protocol using the WRITE
> SAME
> command for two completely different operations.
> 

Hi Martin
thanks very much for your above comments, very detailed. The case I
encountered is very strange to me as well. I will double check on the
product level.

thanks,
Bean