lkml.org 
[lkml]   [2020]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] scsi: sd: Use UNMAP in case the device doesn't support WRITE_SAME
From
Date
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


\
 
 \ /
  Last update: 2020-10-08 16:25    [W:0.108 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site