SG_SAT_IDENTIFY(8) | SG3_UTILS | SG_SAT_IDENTIFY(8) |
sg_sat_identify - send ATA IDENTIFY DEVICE command via SCSI to ATA Translation (SAT) layer
sg_sat_identify [--ck_cond] [--extend] [--help] [--hex] [--ident] [--len=CLEN] [--packet] [--raw] [--readonly] [--verbose] [--version] DEVICE
This utility sends either an ATA IDENTIFY DEVICE command or an ATA IDENTIFY PACKET DEVICE command to DEVICE and outputs the response. The devices that respond to these commands are ATA disks and ATAPI devices respectively. Rather than send these commands directly to the device they are sent via a SCSI transport which is assumed to contain a SCSI to ATA Translation (SAT) Layer (SATL). The SATL may be in an operating system driver, in host bus adapter firmware or in some external enclosure.
The SAT standard (SAT ANSI INCITS 431-2007, prior draft: sat-r09.pdf at www.t10.org) defines two SCSI "ATA PASS-THROUGH" commands: one using a 16 byte "cdb" and the other with a 12 byte cdb. This utility defaults to using the 16 byte cdb variant. SAT-4 revision 5 added a SCSI "ATA PASS-THROUGH(32)" command. SAT-2 and SAT-3 are now also standards: SAT-2 ANSI INCITS 465-2010 and SAT3 ANSI INCITS 517-2015 . The SAT-4 project is near standardization and the most recent draft is sat4r06.pdf .
Arguments to long options are mandatory for short options as well.
Since the response to the IDENTIFY (PACKET) DEVICE command is very important for the correct use of an ATA(PI) device (and is typically the first command sent), a SATL should provide an ATA Information VPD page which contains the similar information.
The SCSI ATA PASS-THROUGH (12) command's opcode is 0xa1 and it clashes with the MMC set's BLANK command used by cd/dvd writers. So a SATL in front of an ATAPI device that uses MMC (i.e. has peripheral device type 5) probably should treat opcode 0xa1 as a BLANK command and send it through to the cd/dvd drive. The ATA PASS-THROUGH (16) command's opcode (0x85) does not clash with anything so it is a better choice.
Prior to Linux kernel 2.6.29 USB mass storage limited sense data to 18 bytes which made the --ck_cond option yield strange (truncated) results.
These examples use Linux device names and a Linux utility called hdparm. For suitable device names in other supported Operating Systems see the sg3_utils(8) man page.
In this example /dev/sdb is a SATA 2.5" disk connected via a USB (type C connector) dongle that implements the UAS (USB attached SCSI) protocol (also known as UASP). UAS is a vast improvement over the USB mass storage class.
# sg_sat_identify /dev/sdb
Response for IDENTIFY DEVICE ATA command:
00 0c5a 3fff c837 0010 0000 0000 003f 0000 .Z ?. .7 .. .. .. .? ..
....
The hexadecimal ASCII (with plain ASCII to the right) output is abridged to a single line (i.e. the first 16 bytes (or 8 words)). Now to decode some of that ATA Identify response. First sg_inq can decode a few strings:
# sg_sat_identify -HHHH /dev/sdb | sg_inq --ata -I -
ATA device: model, serial number and firmware revision:
ST9500420AS 5VJCE6R7 0002SDM1
For a lot more details, the hdparm utility is a good choice:
# sg_sat_identify -HHH /dev/sdb | hdparm --Istdin
ATA device, with non-removable media
Model Number: ST9500420AS
Serial Number: 5VJCE6R7
Firmware Revision: 0002SDM1
Transport: Serial
Standards:
....
There are about 80 more lines of details decoded by hdparm in this case. Notice the difference in the number of "H" options: three give an unadorned hex output arranged in (little endian) words (i.e. 16 bits each) while four "H" options give an unadorned hex output in bytes (i.e. 8 bits each).
The exit status of sg_sat_identify is 0 when it is successful. Otherwise see the sg3_utils(8) man page.
Written by Douglas Gilbert
Report bugs to <dgilbert at interlog dot com>.
Copyright © 2006-2018 Douglas Gilbert
This software is distributed under a FreeBSD license. There is NO warranty;
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
sg_vpd(sg3_utils), sg_inq(sg3_utils), sdparm(sdparm), hdparm(hdparm)
January 2018 | sg3_utils-1.43 |