Date: Wed, 08 Jan 2014 16:07:59 -0500 From: Douglas Gilbert <dgilbert@interlog.com> To: Steven Hartland <killing@multiplay.co.uk>, Garrett Wollman <wollman@csail.mit.edu>, freebsd-scsi@freebsd.org Subject: Re: Attempting ATA TRIM on SAS devices? Message-ID: <52CDBE2F.5030500@interlog.com> In-Reply-To: <430F34AB88D44C4BAF31DDC7AD214137@multiplay.co.uk> References: <21197.39676.138433.937002@khavrinen.csail.mit.edu> <430F34AB88D44C4BAF31DDC7AD214137@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
A SATA disk with a SCSI to ATA Translation Layer (SATL)
in front of it can look like a SCSI disk. If the
SATL is well written such as the ones found in
LSI SAS HBAs then VPD page 0x89 ("ATA Information") will
be present.
Rather than try to read that VPD page, just try to
read VPD page 0x0 which is the "Supported VPD pages"
page. Then look for 0x89 in the response.
Also any "real" SCSI disk should not support either
ATA COMMAND PASS THROUGH command (12 or 16 byte). And
they really should yield sense data of ILLEGAL REQUEST,
Invalid command operation code (0x20,0). Below the
log reports "Invalid field in CDB" (0x24,0) which many
real SCSI devices and SATLs sloppily report. Also any device
that reports such an error should also report the "field
pointer sense key specific information". That pinpoints
_which_ field the device doesn't like. In the unlikely
event that the device does the "right thing" and reports
that, FreeBSD should output that in its log. There is no
sign of that below.
Also if it is a SCSI disk then ATA's trim corresponds to
either the SCSI UNMAP command or WRITE SAME command with
the UNMAP bit set. Also ATA's trim command is broken with
respect to SATA's NCQ (queuing) **, no such problem with
SCSI disks.
Doug Gilbert
** I think a fix for that is in the pipeline.
On 14-01-08 03:36 PM, Steven Hartland wrote:
> It should only do this if your drive reports it supports
> ATA_TRIM by setting the ATA_SUPPORT_DSM_TRIM bit in the
> response to an ATA_IDENTIFY command sent to it using ATA
> passthrough.
>
> What does the following report:
> camcontrol identify da12
>
> Regards
> Steve
>
> ----- Original Message ----- From: "Garrett Wollman" <wollman@csail.mit.edu>
> To: <freebsd-scsi@freebsd.org>
> Sent: Wednesday, January 08, 2014 6:37 PM
> Subject: Attempting ATA TRIM on SAS devices?
>
>
>> On a freshly-installed 9.2 system, I see the following:
>>
>> (da12:mps0:0:59:0): ATA TRIM failed, switching to UNMAP BIO_DELETE
>> (da12:mps0:0:59:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0d 06 00 01 00 01 00
>> 00 00 00 00 00 40 06 00 (da12:mps0:0:59:0): CAM status: SCSI Status Error
>> (da12:mps0:0:59:0): SCSI status: Check Condition
>> (da12:mps0:0:59:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
>> (da12:mps0:0:59:0): Error 22, Unretryable error
>> (da35:mps0:0:82:0): ATA TRIM failed, switching to UNMAP BIO_DELETE
>> (da35:mps0:0:82:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0d 06 00 01 00 01 00
>> 00 00 00 00 00 40 06 00 (da35:mps0:0:82:0): CAM status: SCSI Status Error
>> (da35:mps0:0:82:0): SCSI status: Check Condition
>> (da35:mps0:0:82:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
>> (da35:mps0:0:82:0): Error 22, Unretryable error
>>
>> da12 and da35 are identified as follows:
>>
>> [root@nfs-prod-3 /export]# camcontrol inquiry da12
>> pass13: <OCZ TALOS2 2.25> Fixed Direct Access SCSI-5 device pass13: Serial
>> Number A179E011337000251 pass13: 600.000MB/s transfers, Command Queueing Enabled
>> [root@nfs-prod-3 /export]# camcontrol inquiry da35
>> pass36: <OCZ TALOS2 2.25> Fixed Direct Access SCSI-5 device pass36: Serial
>> Number A179E011337000234 pass36: 600.000MB/s transfers, Command Queueing Enabled
>>
>> Why would it be trying ATA commands here? These are SAS devices.
>>
>> -GAWollman
>> _______________________________________________
>> freebsd-scsi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
>>
>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise disseminating
> it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to postmaster@multiplay.co.uk.
>
> _______________________________________________
> freebsd-scsi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CDBE2F.5030500>