From owner-freebsd-scsi@FreeBSD.ORG Sat Dec 24 17:35:02 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9F0106564A; Sat, 24 Dec 2011 17:35:01 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6858FC0A; Sat, 24 Dec 2011 17:35:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id DA6B42041B4; Sat, 24 Dec 2011 18:17:34 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPKY7HZvpYXq; Sat, 24 Dec 2011 18:17:29 +0100 (CET) Received: from [192.168.48.66] (unknown [216.99.50.73]) by smtp.infotech.no (Postfix) with ESMTPA id 3D507204189; Sat, 24 Dec 2011 18:17:27 +0100 (CET) Message-ID: <4EF60926.7030204@interlog.com> Date: Sat, 24 Dec 2011 12:17:26 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Motin References: <4EF5E134.9040903@FreeBSD.org> In-Reply-To: <4EF5E134.9040903@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: SCSI UNMAP (TRIM) support X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 17:35:02 -0000 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