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
