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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
