RFC: SCSI UNMAP (TRIM) support

[Douglas Gilbert]

On 11-12-24 09:27 AM, Alexander Motin wrote:
> Hi.
>
> I've implemented patch for logical block provisioning (aka UNMAP, TRIM,
> BIO_DELETE) support for the CAM da driver in HEAD and would like to ask for
> review, testing and hardware support information.
>
> Depending on device capabilities I use several different methods to implement
> it. Method can be read/set via kern.cam.da.X.delete_method sysctls. Possible
> values are:
> NONE - no provisioning support reported by the device;
> DISABLE - provisioning support was disabled because of errors;
> ZERO - use WRITE SAME (10) command to write zeroes;
> WS10 - use WRITE SAME (10) command with UNMAP bit set;
> WS16 - use WRITE SAME (16) command with UNMAP bit set;
> UNMAP - use UNMAP command.
> Last two methods (UNMAP and WS16) are defined by SBC specification and UNMAP
> method is the most advanced one. The rest of methods I've found supported in
> Linux, and as soon as they were trivial to implement, then why not? Hope they
> will be useful in some cases.
>
> Unluckily at this moment I have no devices reporting parameters of the logical
> block provisioning support via respective VPD pages (0xB0 and 0xB2). So all info
> I have/use now is the flag telling whether logical block provisioning is
> supported or not. As result specific methods chosen now by trying different ones
> in order (UNMAP, WS16, DISABLE) and checking completion status to fallback if
> needed. I don't expect problems from this, as if something go wrong, it should
> just disable itself. It may disable even too aggressively.
>
> Unlike Linux, which executes each delete with separate request, I've implemented
> here the same request aggregation as implemented in ada driver. Tests on SSDs I
> have show much better results doing it this way: above 8GB/s of the linear
> delete on Intel SATA SSD on LSI SAS HBA (mps).
>
> The patch can be found here:
> http://people.freebsd.org/~mav/scsi_unmap.patch
>
> Work sponsored by iXsystems, Inc.
>
> If somebody has SAS SSDs with UNMAP support, I would be grateful for additional
> information about them, such as:
> camcontrol cmd da0 -c "12 01 00 00 ff 00" -i 255 - >pages
> camcontrol cmd da0 -c "12 01 b0 00 ff 00" -i 255 - >page_b0
> camcontrol cmd da0 -c "12 01 b2 00 ff 00" -i 255 - >page_b2
> camcontrol cmd da0 -c "9e 10 00 00 00 00 00 00 00 00 00 00 00 ff 00 00" -i 255 -
>  >rc16

You might find my sg3_utils package useful. It builds on
FreeBSD and contains sg_vpd, sg_readcap and sg_unmap
which may be more convenient than "bit-banging" through
'camcontrol cmd'. See:
http://sg.danny.cz/sg/sg3_utils.html

The above sequence would be:
   sg_vpd /dev/da0
   sg_vpd -p 0xb0 /dev/da0
   sg_vpd -p 0xb2 /dev/da0
   sg_readcap -l /dev/da0

If you want the response in hex rather than decoded, add a
'-H' option (for binary add a '-r' option).

In Linux we can test the SCSI UNMAP command against SATA SSDs
due to the SATL inside libata. It is actually a lousy SATL,
LSI have a much better one in firmware in their MPT Fusion
SAS-2 HBAs (but I think "IT" rather than "IR" firmware may
be needed).

True SAS SSDs are a bit thin on the ground. Hopefully more will
emerge with SAS-3 (12 Gbps) and perhaps using the dual phys
on a standard SAS disk connector as a single port: more
bandwidth, less redundancy.

Doug Gilbert