The sdparm utility

Introduction

The sdparm utility accesses SCSI device parameters. When the SCSI device is a disk, sdparm's role is similar to its namesake: the Linux hdparm utility which is primarily designed for ATA disks that had device names starting with "hd". More generally sdparm can be used to access parameters on any device that uses a SCSI command set. Apart from SCSI disks, such devices include CD/DVD drives (irrespective of transport), SCSI and ATAPI tape drives and SCSI enclosures. A small set of commands associated with starting and stopping the media, loading and unloading removable media and some other housekeeping functions can also be sent with this utility.

This utility currently contains over 500 entries spread across generic mode pages, transport specific mode pages, vendor specific mode pages, Vital Product Data (VPD) pages and their fields. Rather than try and document all of these here (or in the man page), another approach is taken. This utility's internal tables can be searched and output with the '--enumerate' option. Additional explanatory information is output when the '--long' option is used (and still more if the '--long' option is used twice).

The information in this page corresponds to sdparm version 1.10 . This utility was originally written for Linux and now has been ported to FreeBSD, Solaris, Tru64, and Windows.

SCSI mode pages

Mode pages hold meta data about a SCSI device which can, in some cases, be changed by the user. In SCSI parlance the "device" is a logical unit of which there may be several in a SCSI target. In the case of a SCSI disk directly connected to a Host Bus Adapter (HBA) the disk is both a SCSI target and a logical unit. The "user" in this case is the person using sdparm which is a SCSI application client and it feeds commands into a SCSI initiator. The SCSI initiator is found in the HBA. At the command level, SCSI is a client-server protocol with the logical unit (or target device) being the server that responds to commands sent by the application client via the SCSI initiator.

Mode pages are defined in SCSI (draft) standards found at www.t10.org . Mode pages common to all SCSI devices are found in the SCSI Primary Commands document (SPC-4) while those specific to block devices (e.g. disks) are found in SBC-3 and those for CD/DVD drives are found in MMC-6. This diagram shows how various SCSI and associated standards interrelate.

Below is a representation of the control mode page taken from SPC-3 (draft revision 23). The page is 12 bytes long with bytes numbered from 0 to 11. The bits within each byte are numbered from 0 to 7 (with 0 on the right and 7 on the left). Note that some fields occupy a single bit, others multiple bits, while the last two fields occupy two bytes (i.e. 16 bits) each.

control mode page
representation

Often device product manuals detail precisely which mode pages (and fields within those pages) are supported by a particular model. They describe the way that the device will react if the generic description in the SCSI (draft) standard needs amplification. There are also transport protocol specific mode pages for transports such as "spi" (the 25 year old SCSI Parallel Interface), "fcp" (Fibre Channel Protocol) and "sas" (Serial Attached SCSI). There are also vendor specific mode pages. Mode pages that are not transport protocol specific and are not vendor specific are sometimes referred to as "generic" in sdparm's documentation.

To see a list of generic mode page names that sdparm has some information about use: 'sdparm -e'. To see a list of transport specific mode page names that sdparm has some information about use (for example) 'sdparm -e -t sas'. Both lists are sorted alphabetically by mode page abbreviation.

The majority of mode pages are fixed length, like the control mode page shown above. There are some mode pages that are variable length, typically with a fixed header at the top of the mode page (often 8 bytes long) followed by a variable number of descriptors. The descriptors themselves may be either be fixed length or contain a length field.

Mode pages are not the only mechanism in SCSI devices for holding meta data. Information which seldom if ever changes for a particular device may be found in the Vital Product Data (VPD) pages which are obtained via the SCSI INQUIRY command. Performance statistics are held in log pages which are obtained via the SCSI LOG SENSE command. Recent CD/DVD drives hold a lot of information in feature and profile descriptors (see MMC-4 and MMC-5) which are accessed via the SCSI GET CONFIGURATION command (see the sg_get_config utility in the sg3_utils package).

Each mode page has up to four tables associated with it. These can be thought of like tabs on a spreadsheet, with each tab containing the same size table. The four tables are:

current values: those values that are active at this time
changeable values: bit masks showing those values that the user may change
default values: the manufacturer's default values
saved values: those values that will be active after the next power cycle (or format)

The saved values are optional. If the mask in the changeable values indicates a field can be changed then the corresponding field in the current values may be changed. A bit of 0 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may not be changed. A bit of 1 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may be changed. At the point when a current value is changed, the user may also choose to change the corresponding saved value.

If all of the bits in a changeable mask corresponding to a field are zero then this is indicated in most sdparm output by the string "cha: n" on the same line as the field name. For example: "SWP 0 [cha: n, def: 0, sav: 0]". If any bits in a changeable mask corresponding to a field are one (i.e. set) then this is indicated in sdparm output by "cha: y". sdparm will not stop a user from trying to change a field marked as not changeable. Most often the result will be no error reported but also no change to the current field value either. Sometimes an error is reported (and at least one vendor has a setting in a vendor specific mode page to control whether such a futile action is just ignored or causes an error). In some rare cases the changeable mask may be wrong and a change will be accepted.

The manufacturer obviously knows a lot about the characteristics of its devices. Hence if a current field value (and saved field value) is different from the default field value then there should be some rationale.

Some current values represent a state within the target device or logical unit. If that state changes so does the current value. Such values are not usually changeable by the user.

The sdparm utility has a '--get', '--set', '--clear' type of command line interface in which mode page fields are identified by an acronym_name. In many cases these acronym_names will correspond precisely to the standard (e.g. "WCE" for Writeback Cache Enable in the caching mode page of SBC-3). For some longer fields the standards "spell out" a field name (e.g. "Write Retention Priority" in the caching mode page of SBC-3). In such cases the sdparm utility uses an acronym_name (e.g. "WRP"). In sdparm, acronyms across all generic mode pages are unique (i.e. an acronym matches at most one field of one generic mode page). Each transport protocol has its own namespace of acronyms so that an acronym is unique within a transport protocol. By default, saved values are not changed by '--set' and '--clear'. When changing the current values, the saved values can be changed as well by adding the '--save'. All the current values in a mode page can be changed back to the manufacturer's defaults with the '--defaults' option (and the '--save' option here will additionally change the saved values back to the manufacturer's defaults).

For mode pages that are variable length, fields that are in the header section or the first descriptor appear as normal. For example the "PID" (phy identifier) field in the first descriptor of the SAS phy control and discover mode page appears as is (e.g. '--get PID'). The same field in subsequent descriptors is addressed by a "<acronym>.<desc_num>" format. Hence that field in the second descriptor is named "PID.1" and if there is a third descriptor the corresponding acronym_name will be "PID.2 ". So the "<desc_num>" is origin zero and is assumed to be 0 if not given.

Changing some mode page fields is like jumping off a cliff holding onto a rope which you are not sure is properly secured. If in doubt, change the current value without using the '--save' option. That way if the setting is disastrous, power cycling the device will restore the previous setting. Once the new setting is known to be safe, then the sdparm utility can be re-executed with the '--save' option added.

The sdparm utility does not decode SCSI log pages. The sg_logs utility in the sg3_utils package decodes log pages.

VPD pages

Vital Product Data (VPD) pages are fetched with the SCSI INQUIRY command. While support for a "standard" INQUIRY response is mandatory, support for VPD page has been optional in the past. SPC-2 (which became a standard in 2001) and SPC-3 (ANSI INCITS 408-2005) made support for the "Device Identification" and the "Supported VPD pages" VPD pages mandatory. A utility like sdparm should be able to send an INQUIRY command and get a valid response when the target device or logical unit is in almost any state. SCSI devices are not required to respond to mode pages accesses when the device is in any state For example, often disk drives will not allow mode pages to be accessed or changed when the disk is spun down.

VPD pages are read only and in some situations may not be available (e.g. if the media is spun down or not present). Even in such cases the INQUIRY command should still respond with perhaps zero in the affected fields. VPD pages tend to have a variable number of descriptors rather than a predictable size with parameters in known positions such as most mode pages. A VPD page number can be selected with the '--page=' option. If only the '--inquiry' option is given (without a '--page=' option) then the Device Identification VPD page (page number 0x83 or abbreviation "di") is assumed. If both the '--inquiry' and '--all' options are given (without a '--page=' option) then the Supported VPD pages VPD page (page number 0x0 or abbreviation "sv") is assumed.

The device identification page usually contains multiple designators. Each designator belongs to one of three associations. The SCSI Architectural Model (see SAM-3 at www.t10.org) may help in explaining these associations. The associations are:

addressed logical unit
target device port (that, in most cases, received the request)
target device containing addressed logical unit

Any designators found are grouped in the order of the above list. If there are no designators of a given type of association then the heading for that association is not output. Each association can be listed individually with the "di_lu", "di_port" and "di_target" acronyms. For debugging there is another acronym: "di_asis" which outputs designators in the order they are found in the device identification page.

Here are some of the VPD pages that are currently decoded (listed in page number order):

Supported VPD pages [page 0x0]; page abbreviation: "sv". Contains a list of VPD pages supported by given device.
Unit serial number [page 0x80]; page abbreviation: "sn". This is a vendor specific (vendor format) serial number.
Device identification [page 0x83]; default, page abbreviation: "di". Contains designators for the addressed logical unit, target device and target port. These can be listed individually with the "di_lu", "di_port" and "di_target" acronyms. Use "di_asis" to show all designators in the order they are found. Add '--quiet' option to reduce the amount of output, leaving mainly naa-5 and EUI identifiers.
Software Interface Identification; [page 0x84], one or more EUI-48 identifiers that can be used to define more precisely the peripheral device type.
Management network addresses: [page 0x85], page abbreviation: "mna". Contains a list of network addresses of associated management services.
Extended inquiry: [page 0x86], page abbreviation: "ei". The standard INQUIRY response is full, so further options that don't fit into other pages are placed here.
Mode page policy: [page 0x87], page abbreviation: "mpp". Contains a list of supported mode pages and their associated policy (e.g. for a dual ported disk, mode pages can be per target port or shared).
SCSI Ports [page 0x88]; page abbreviation: "sp". For dual ported devices (e.g. SAS and FCP disks), contains all port addresses (not just the one being used for this access).
ATA Information [page 0x89 (SAT)]; page abbreviation: "ai". Defined by the SCSI to ATA Translation (SAT) draft standard. Contains IDENTIFY (PACKET) DEVICE ATA command response and some related information.
Block limits [page 0xb0 (SBC)]; page abbreviation: "bl". Defines maximum and optimal number of blocks to transfer in a single SCSI command (either a READ or WRITE command)
Block device characteristics [page 0xb1 (SBC)]; page abbreviation "bdc". Contains the rotating media revolutions per minute (rpm) where relevant.

VPD pages for which sdparm does not hold decoding information (e.g. '--page=82h') are output in ASCII hex, assuming the device responds. VPD page abbreviations can be listed with 'sdparm --enumerate --inquiry'.

The sg3_utils package contains a utility called sg_vpd that overlaps with sdparm's VPD capabilities. Additionally sg_vpd decodes various vendor specific VPD pages.

sdparm commands

The '--command=' option allows a command to be sent to the given device. The currently supported commands are:

capacity: sends a READ CAPACITY and if successful reports the number of blocks, block length and capacity expressed in MibiBytes (1048576 bytes). Valid for disks and CD/DVD drives with the appropriate media loaded.
eject: stops the medium (if it is spinning) and ejects it from the drive. Note that this may be prevented by software in which case use the 'unlock' command first.
load: loads the medium and then spins it up
profile: lists the profiles (e.g. DVD+R and DVD-RAM) supported by a CD/DVD/HD_DVD/BD drive. If media is present in the drive then its corresponding profile has an asterisk ("*") to its right in the list.
ready: reports whether the medium is ready for IO. Ready usually means that it is present and spun up. If the device is not ready then the exit status will be 2 (see exit status section below).
sense: reports sense data (from a REQUEST SENSE SCSI command); can include power condition information, a progress indication for a time consuming command (e.g. format) or a report an informational exception (when MRIE=6)
speed: takes and argument (e.g. --command=speed=1350 or -C sp=1350 ) which is in kilobytes per second (1000 bytes per second units). Attempts to set CD/DVD/BD media to given read speed. If argument is zero then set drive back to its optimum setting. "Times one" speeds are 177 kB/s for CD, 1350 kB/s for DVD and 4500 kB/s for HD-DVD and BD.
start: spin up the medium
stop: spin down the medium (may require the --readonly option)
sync: send a SYNCHRONIZE CACHE SCSI command to the device.
unlock: instructs the device to allow medium removal (i.e. an eject). Beware, the OS may have had a good reason for preventing removal of the medium (e.g. it contains a mounted file system). Use at your own risk.

The command names can be abbreviated to two letters unless that leads to ambiguity (e.g. start and stop can be abbreviated to sta and sto).

Due to some quirks introduced in Linux around lk 2.6.30 (but not necessarily by the kernel itself) using 'sdparm --readonly --command=stop /dev/sdc' may be required to spin down an ATA disk (behind a SAT layer). Without the '--readonly' option nuisance commands are sent to the ATA disk when the sdparm invocation completes and these restart the disk.

These sdparm commands send SCSI commands to the given DEVICE. If they don't seem to work, adding a verbose flag (i.e. '-v' or '-vv') may provide more information. The "ready" and "sense" commands need read permissions on the DEVICE while the other commands need both read and write permissions.

sdparm syntax

sdparm is a command line utility which takes the following form:
sdparm [OPTIONs] DEVICE [DEVICE...]

There are zero or more options usually followed by one or more DEVICE names. Only invocations that use the '--enumerate' or '--wscan' option do not need a DEVICE name. Invocations with a DEVICE name and no options will check that device for mode pages in which there are "common" parameters (mode page fields). Common parameters are a somewhat arbitrary subset of the hundreds of parameters available.

Options have either a long format, as shown in the first column below, or a short format, as shown in the second column. Either format can be used. Note that long options that take an argument (e.g. '--get=WCE') use an equal sign ("=") as a separator while the corresponding short options use a space (or nothing) as a separator (e.g. '-g WCE'). Short options can be elided, hence '-al' is equivalent to '--all --long'.

Table 1. sdparm command line options
long option format	short option format	description
--all	-a	list all known (generic or transport) parameters for given DEVICE. When this utility is invoked with no options then only common generic mode parameters are output.
--clear=STR	-c STR	clear (zero) parameter(s) in STR. The default action to clear can be overridden, see below.
--command=CMD	-C CMD	perform CMD which is one of: capacity, eject, load, ready, sense, start, stop, sync or unlock
--dbd	-B	set the DBD (disable block descriptors) bit in each MODE SENSE cdb
--defaults	-D	fetch the default values for the given mode page and use them to overwrite the current values. Note that the saved values are not overwritten unless the '--save' option is also given.
--dummy	-d	when used with '--set' or '--clear' does all the preparation and sanity checks but bypasses the final stage of sending the changes to the device. [That is, it skips the MODE SELECT command.]
--enumerate	-e	fetch information from the sdparm's internal tables. If a DEVICE name is given then it will be ignored. May be used in conjunction with '--all', '--inquiry', '--long', '--page=', '--transport=' and/or '--vendor='.
--flexible	-f	check mode sense responses for sanity and if broken, try to fix them if possible. Also allows mode pages whose peripheral type mismatches the given DEVICE to be processed.
--get=STR	-g STR	fetch parameter(s) in STR
--help	-h	output a usage message then exits
--hex	-H	rather than decode a (mode or VPD) page, it is output in ASCII hex. If used with the '--get' option then the parameter is output in hexadecimal. May be invoked multiple times.
--inhex=FN	-I FN	read ASCII hex from file FN (and ignore DEVICE) and decode as mode or VPD page(s). Reads from stdin if FN is '-'. Treats the contents of FN as binary if '`--raw`' is also given.
--inquiry	-i	fetch a VPD page, decode and output it. If no '--page=' is given then the device identification VPD page is fetched. Add '-ll' to get standard INQUIRY response data decoded in more detail.
--long	-l	Add extra information to the output. For example a line showing the setting of the WCE parameter will have "Write cache enable" appended to it. Using '-ll' adds information about selected mode parameter values (e.g. MRIE).
--num-desc	-n	for a mode page that can have descriptors, the number of descriptors in the given page on DEVICE is output. Otherwise 0 is output.
--page=PG[,SPG]	-p PG[,SPG]	page (and optionally subpage) to output or change. Argument may be either an abbreviation, a number or two numbers separated by a comma. If a number is prefixed by "0x" or has a trailing "h" then it is decoded as hexadecimal. When a numeric argument is given, it is assumed to be for a mode page unless the '--inquiry' option is also given. An abbreviation is two or three lower case letters (e.g. "ca" for the caching mode page). An abbreviation may be for a mode page (e.g. "ca") or a VPD page (e.g. "sp").
--pdt=DT	-P DT	where DT is the "peripheral device type" value (e.g. 0 for a disk, 1 for a tape drive, etc). Only active when '`--inhex=``FN`' is also used.
--quiet	-q	suppress vendor/product/revision strings that are usually the first line of the output. Also abridges the output of the device identification VPD page.
--raw	-R	used together with '`--inhex=``FN`'. It causes the file FN to be interpreted as binary.
--readonly	-r	override other logic and open DEVICE in read-only mode. This can help with ATA disks especially with commands like '-C stop'. Also works with '`--set=`' and '`--clear=`'.
--save	-S	also write changes to corresponding "saved" values mode page. Active when used with '--set=', '--clear=' or '--defaults'. The default action is to only make changes to the current values mode page.
--set=STR	-s STR	set parameter(s) in STR. To set a parameter is to make all its bits one. The default action to set can be overridden, see below.
--six	-6	use 6 byte cdbs for MODE SENSE and MODE SELECT commands for getting and setting mode pages. The default action is to use the 10 byte cdb variants.
--transport=TN	-t TN	transport protocol identifier; either a number or an abbreviation (e.g. "fcp", "spi" or "sas") can be given. See transports section. In the absence of an explicit transport and if a page or field name does not match a generic name then the SAS transport is assumed.
--vendor=VN	-M VN	vendor (manufacturer) identifier; either a number or an abbreviation (e.g. "sea" or "hit") can be given. See vendors section.
--verbose	-v	increase verbosity of output. May be used multiple times to further increase verbosity.
--version	-V	print out the version and the date of last code change then exits
--wscan	-w	[Windows only] scan for device names, show one device per line. Each device can have multiple device names. If a DEVICE name is given (on the command line) then it will be ignored.

If neither '--transport=' nor '--vendor=' options are given for mode page related operations then generic mode pages and fields are checked first for matches. If there is no match then the SAS transport is checked. This means that in most cases the '--transport=sas' option is not required when accessing SAS mode pages and fields.

The '--clear=', '--get=' and '--set=' options require a "STR" argument. The STR argument is a comma separated list of acronyms or numeric descriptors. Each acronym or numeric descriptor can optionally be followed by "=<value>". The "<value>" is assumed to be decimal unless prefixed by "0x" or has a trailing "h". Numeric descriptors are three numbers separated by colons of the form: "<start_byte>:<start_bit>:<num_of_bits> . The <start_byte> begins at zero; the <start_bit> is 7 for the most significant bit (msb) and 0 for the least significant bit; while the <num_of_bits> should be a value between 1 and 64 inclusive.

For '--clear=' and '--set=' the optional "<value>" is the unsigned integer value to set that parameter to (e.g. '--set=MRIE=6'). The "<value>" of -1 is a special case in which all the bits in the parameter are set to one. For a '--set=' option the default action (in the absence of "=<value>") is the same as "=-1". For a '--clear=' option the default action (in the absence of "=<value>") is the same as "=0".

If sdparm is used to change parameters and that operation succeeds (or at least no error is reported) then only standard INQUIRY response information (i.e. vendor, model and revision) is output and the sdparm completes with an exit status value of 0. If required the standard INQUIRY response information (i.e. vendor, model and revision) output can be suppressed with the '--quiet' option. If sdparm is used to change parameters and that operation fails then error information is output (usually to stderr) and the sdparm completes with a non-zero exit status value(see exit status section).

For '--get=' the "<value>" is not normally given. If given then it is interpreted as a formatting instruction for which the value of 0 is the default. For mode pages the default format for '--get=' is the acronym followed by the current value and then the changeable, default and saved values in brackets. If a value of 1 is given then only the acronym followed by the current value are output.

The '--enumerate' option ignores the given device name (if provided) and outputs information from the tables within the sdparm utility. With no other options provided, mode page abbreviations followed by their full names are output. If the '--inquiry' option is also given the VPD page abbreviations followed by their full names are output. If the '--enumerate --page=' options are given then within the selected mode page, the name of each known acronym, its numeric descriptor and its full name is output. More information about some mode page fields is supplied when additional '--long --long' options are given.

Exit status

Each process containing the sdparm utility completes with an exit status 0 when successful. Prior to version 0.99 all errors yielded an exit status of 1. From version 1.00 the non zero exit status values are:

1 syntax error in command line options or their arguments, or an illegal combination of options.
2 the DEVICE reports that it is not ready for the operation requested. The DEVICE may be in the process of becoming ready (e.g. spinning up but not at speed) so sdparm may work after a wait.
3 the DEVICE reports a medium or hardware error (or a blank check).
5 the DEVICE reports an "illegal request" with an additional sense code other than "invalid operation code". This is often a supported command with a field set requesting an unsupported capability.
6 the DEVICE reports a "unit attention" condition. This usually indicates that something unrelated to the requested command has occurred (e.g. a device reset) potentially before the current SCSI command was sent. The requested command has not been executed by the DEVICE. Note that unit attention conditions are usually only reported once by a device.
7 the DEVICE reports a "data protect" sense key. This implies some mechanism has blocked writes (or possibly all access to the media).
9 the DEVICE reports an illegal request with an additional sense code of "invalid operation code" which means that it doesn't support the requested command.
11 the DEVICE reports an aborted command. In some cases this can be caused by congestion on the transport and trying again may be successful.
14 the DEVICE reports a miscompare sense key. VERIFY and COMPARE AND WRITE commands may report this.
15 sdparm is unable to open, close or use the given DEVICE or FN (as used by '--inhex='). The given file name could be incorrect or there may be permission problems. Adding the '-v' option may give more information.
20 the DEVICE reports it has a check condition but "no sense". Some polling commands (e.g. REQUEST SENSE) can react this way. It is unlikely that this value will occur as an exit status.
21 the DEVICE reports a "recovered error". The requested command was successful.
24 the DEVICE reports a SCSI status of "reservation conflict". This means access to the DEVICE with the current command has been blocked because another machine (HBA or SCSI "initiator") holds a reservation on this DEVICE. On modern SCSI systems this is related to the use of the PERSISTENT RESERVATION family of commands.
25 the DEVICE reports a SCSI status of "condition met". Currently only the PRE-FETCH command (see SBC-4) yields this status.
26 the DEVICE reports a SCSI status of "busy". SAM-5 defines this status as the logical unit is temporarily unable to process a command. It is recommended to re-issue the command.
27 the DEVICE reports a SCSI status of "task set full".
28 the DEVICE reports a SCSI status of "ACA active". ACA is "auto contingent allegiance" and is seldom used.
29 the DEVICE reports a SCSI status of "task aborted". SAM-5 says: "This status shall be returned if a command is aborted by a command or task management function on another I_T nexus and the Control mode page TAS bit is set to one".
33 the command sent to the DEVICE has timed out.
40 the command sent to DEVICE has received an "aborted command" sense key with an additional sense code of 0x10. This group is related to problems with protection information (PI or DIF). For example this error may occur when reading a block on a drive that has never been written (or is unmapped) if that drive was formatted with type 1, 2 or 3 protection.
97 the response to a SCSI command failed sanity checks.
98 the DEVICE reports it has a check condition but the error doesn't fit into any of the above categories.
99 any errors that can't be categorized into values 1 to 98 may yield this value. This includes transport and operating system errors after the command has been sent to the DEVICE.
126 the utility was found but could not be executed. That might occur if the executable does not have execute permissions.
127 this is the exit status for utility not found. That might occur when a script calls a utility in this package but the PATH environment variable has not been properly set up, so the script cannot find the executable.
128+<signum> if a signal kills a utility then the exit status is 128 plus the signal number. For example if a segmentation fault occurs then a utility is typically killed by SIGSEGV which according to 'man 7 signal' has an associated signal number of 11; so the exit status will be 139 .
255 the utility tried to yield an exit status of 255 or larger. That should not happen; given here for completeness.

Many of the above exit statuses will be repeatable so executing sdparm again with one or more '-v' options may yield more information. Unit attentions (exit status 6) are only reported once per condition. Notice that some of the lower exit status values (e.g. 2 to 11) correspond to the SCSI sense key values.

Transports

There are a basically two command set families of interest for storage devices: those defined at www.t10.org ("SCSI") and the ATA non-packet command set for disks (reference: ATA8-ACS at www.t13.org ). Transports carry commands and associated data across some interconnect. Examples of transports are PATA (parallel ATA), SATA, SPI, SAS, FCP, USB and IP (for iSCSI). The ATA transports have a pass-through interface for carrying packet oriented command sets and that is called ATAPI. ATAPI is used almost exclusively to carry SCSI command sets (e.g. MMC for CD/DVD drives). SAS and FCP are considered "SCSI" transports yet they can also carry (or tunnel) the ATA non-packet command set for disks as well as other non-SCSI protocols.

Should we name devices in an operating system by transport or command set? That is a difficult question since transports can be bridged (or tunnelled) while command sets can be translated. Linux has instances of both transport and command set device naming. Awkward examples can be found of both:

/dev/hdc could be an ATAPI DVD drive connected via a parallel ATA ribbon cable. However it responds to very few ATA commands (those for identification and transport characteristics); at the command set level it is a "SCSI" device using the Multi Media Command (MMC) set.
/dev/sda could be a Compact Flash card, plugged into a USB multi-card reader which is connected to the computer with a USB cable. The device node name suggests it is a SCSI device yet its transport is obviously USB while the CF card itself uses a parallel ATA bus and command set.

Sometimes the command set layer is used to fetch or perhaps change transport characteristics of a given device (e.g. a disk at the other end of a cable). Alternatively the management of the transport is done by other protocols (e.g. IP in the case of iSCSI). Of the 9 transports defined in SCSI (SPC-4) only the following have transport (protocol) specific mode pages for transport management, according to current drafts:

Fibre channel [abbreviation "fcp"]
SCSI parallel interface [abbreviation "spi"]
SCSI Remote DMA used by InfiniBand [abbreviation "srp"]
Serial attached SCSI [abbreviation "sas"]

These transports all have a protocol specific Disconnect/reconnect mode page, and most have additional mode pages. All supported generic and protocol (i.e. transport) specific modes pages can be listed (enumerated) with the '--enumerate --long' option. Mode pages for a given transport can be listed with, for example, the '--enumerate --transport=sas' option. All parameters of mode pages for a given transport can be listed with, for example, the '--enumerate --transport=sas --all' option.

There are other significant "mass storage" transports that are not listed in SPC-4. See the following sections.

USB

Until recently SCSI standards at t10.org said little to nothing about USB. That changed with USB Attached SCSI (UAS) which is a new SCSI transport approaching standardization. UAS is designed to more efficiently carry large amounts of data associated with storage devices. UAS will most likely be available with USB-3 but there is no reason why it couldn't also be stacked over USB-2 hardware.

Prior to UAS the SCSI related information for USB can be found at www.usb.org/developers/devclass_docs under "Mass storage". There are no transport specific mode pages defined for the USB mass storage class. Typically a USB external disk enclosure contains a parallel or serial ATA disk while USB external CD/DVD drives normally contain parallel ATAPI devices. Often there is a protocol bridge chip within a USB enclosure to do a SCSI to ATA translation and is often ugly but some recent devices follow the SCSI to ATA Translation (SAT) standard. There are also USB memory keys (containing flash ram) and USB Compact Flash (CF), Secure Digital (SD), etc, card readers. CF cards use the ATA interface between the card and the reader, while many other card types use proprietary interfaces. Multi card USB readers tend to use SCSI LUNs for sub-addressing within the multi card reader (which is exactly what LUNs are designed to do).

Within the USB mass storage class there is a subclass code. For disks, the applicable subclasses are either Reduced Block Commands (RBC) or SCSI "transparent" (i.e. SBC). The RBC standard must be the most quirky standard in the t10.org stable. RBC has a peculiar mode page called "RBC device parameters" mode page which combines parameters from several other mode pages (and the READ CAPACITY SCSI command) in a rather awkward way. RBC only supports the 6 byte variants of MODE SENSE and MODE SELECT and requires the "disable descriptor blocks" (DBD) bit to be set, both of which are at odds with the conventions of other t10.org standards. Since RBC can trip up the SCSI disk (sd) driver, the USB mass storage driver does its own translation so RBC is somewhat hidden. Around Linux kernel 2.6.13 the sd driver has been corrected to handle the RBC set properly (mainly for IEEE 1394). This discussion suggests that the way to read the RBC device parameters mode page is something like 'sdparm --dbd --six --page=rbc /dev/sdc'; and if that fails try dropping the '--six' option.

In summary, sdparm can do very little with USB mass storage devices. Best to start with very low expectations.

IEEE 1394

This is a similar technology to USB. IEEE1394 has a transport defined at t10.org called SBP-2 (and a new version called SBP-3). There are no transport (protocol) specific mode pages defined in SBP. SBP requires the use of the Reduced Block Commands (RBC) set. The comments about RBC in the USB section apply.

SATA

SATA disks and S-ATAPI devices (e.g. DVD drives) may appear as either IDE (e.g. /dev/hda) or SCSI (e.g. /dev/scd0) devices in Linux. In some cases this may depend on which hardware drivers have been chosen in the kernel configuration. For SATA disks that appear as IDE devices, the Linux's hdparm utility is the appropriate tool. S-ATAPI devices, regardless of their device node name, may find sdparm useful because there is a high probability that they use a SCSI command set (e.g. MMC for DVD drives).

SATA disks that appear as SCSI devices (e.g. /dev/sda) may have a SCSI ATA Translation (SAT) Layer (SATL) between the disk and the host computer. SAT recently became a standard, for more information see www.t10.org . The SATL may be within the kernel (e.g. libata in Linux), in host adapter firmware or in an external enclosure (e.g. Fibre channel has FC to SATA translation chips that include a SATL). [One reason for doing this is that the SCSI protocols scale better in multi-initiator, multi-port environments (e.g. SATA NCQ assumes one host).]

The SAT standard defines a Vital Product Data page for fetching information about ATA devices which includes the response to the IDENTIFY (PACKET) DEVICE ATA command. This is the "ATA Information" VPD page and has the acronym "ai" in sdparm. This page is supported by several SATLs. If present, it can be viewed with 'sdparm --page=ai DEVICE'. The sdparm utility only decodes the device identification strings from the IDENTIFY (PACKET) DEVICE response. The Linux utility hdparm decodes are lot more from the response. The following incantation glues the two utilities together so that hdparm can decode ATA information that sdparm has fetched: 'sdparm --page=ai -HHH /dev/sda | hdparm --Istdin'. Due to difficulties with the older versions of hdparm this sequence may be more stable: 'sdparm --page=ai -HHH /dev/sda > t ; hdparm --Istdin < t' . hdparm version 7.0 and later can detect a SATL so 'hdparm -I /dev/sda' should work if /dev/sda is a SATA disk or a S-ATAPI device (e.g. a CD/DVD drive).

The SAT standard only defines a few fields that can be changed (e.g. DRA and WCE). Setting these requires either:

the ATA PASS-THROUGH SCSI commands in the SATL to be implemented, or
the MODE SELECT SCSI command in the SATL to be implemented so sdparm can do it.

Again Linux's libata is almost, but not yet, there. Both mechanisms will be useful since the ATA PASS-THROUGH commands can be used by utilities like smartmontools while MODE SELECT is required for S-ATAPI devices that use SCSI command sets (e.g. DVD drives which use MMC). If the SATL implements the SCSI MODE SELECT command then sdparm can be used to change the fields.

Vendor specific mode pages

Mode page 0 is reserved for vendor specific information and it is possible that some vendors use other mode pages. Some vendors call mode page 0 the "unit attention" mode page. To see a list of known vendors use 'sdparm -e -M xxx'. To see which mode pages a specific vendor documents (and sdparm has information for) use something like 'sdparm -e -M sea'. Getting, setting and clearing of mode page fields follow the same pattern as all mode pages in sdparm. For example 'sdparm -M sea -p ua -s PM /dev/sdc'.

The information for the vendor specific mode pages and their fields was obtained from (disk) product manuals available on the internet.

Supported operating systems

The sdparm utility was originally written for Linux. It relies on standard Unix features and a SCSI command pass through mechanism. Since it has no other special dependencies, it is reasonably simple to port to other operating systems.

Linux

sdparm is designed for both the 2.6 and 2.4 Linux kernel series. There are some slight differences between the two environments.

In the kernel 2.6 series sdparm uses the SG_IO ioctl which is implemented for all SCSI devices and many other devices that are not considered to be "SCSI" but use a SCSI command set. An example of the latter case is an ATAPI DVD drive which uses MMC (a SCSI command set) and implements the SG_IO ioctl so sdparm will work with it (in the lk 2.6 series). So if "/dev/hdc" is a DVD drive (with or without media in it) then 'sdparm /dev/hdc' should work.

In the kernel 2.4 series sdparm will work on all devices that use the SCSI subsystem. Internally sdparm maps the given SCSI device to the corresponding SCSI generic (sg) device which implements the SG_IO ioctl. Hence an ATAPI DVD drive will only be accessible to sdparm if the device is mapped through to the SCSI subsystem with the ide-scsi driver.

hdparm mapping

The Linux hdparm utility uses command line options in many cases to change or fetch a specific field. These fields can be looked up in the "man page" for hdparm. The sdparm utility uses more generic command line options with acronyms for fields; these acronyms are not defined in sdparm's man page but can be listed (with a short description) with the '--enumerate' option. In both cases the relevant standards and/or product manuals should be consulted before some of these fields are changed.

hdparm covers a wide sweep of attributes: for the kernel block subsystem, for the host interface (to the PATA or SATA transport), for the transport specific fields of the device (at the other end of the cable) and the more general attributes of the device. Even though ATAPI (but not ATA) is recognized as a SCSI transport, there are no standard transport specific mode pages defined for sdparm to access. The main area of overlap between sdparm and hdparm is for general device attributes. For directly attached ATAPI devices (e.g. DVD drive) hdparm can be used to probe and perhaps change transport characteristics while sdparm can be used for more general attributes (e.g. setting the TST_W (test write) field for DVD writing code).

Table 2. hdparm options that have sdparm equivalent
hdparm option	related sdparm option	Comments
-A0	--set DRA=1	disable read look ahead. SAT shows this mapping and libata may support it soon.
-A1	--set DRA=0	enable read look ahead (double negative in sdparm). Check current state with '--get DRA'.
-C	--command=ready or --command=sense	fetch the current device power state. Use of "sense" (i.e. REQUEST SENSE SCSI command) to check the power state is relatively new for SCSI devices. Not many devices will support it yet.
-D0	--set AWRE=0,ARRE=0	disable defect management [SCSI: Automatic Write/Read Reallocation Enabled fields]
-D1	--set AWRE=1,ARRE=1	enable defect management [SCSI: Automatic Write/Read Reallocation Enabled fields]. This is usually enabled by default but is sometimes disabled on disks found in RAIDs.
-f	--command=sync	sdparm sends a SYNCHRONIZE CACHE SCSI command; it does not touch the block layer.
-i	--inquiry	hdparm's '-i' is a reduced (and older form) of what is available with '-I'
-I	--inquiry or --inquiry -ll or --inquiry --page=ai	The closest match here is when the "ai" VPD page is available (i.e. the third related sdparm option). Logically much of the information from '-I' corresponds to information in a standard INQUIRY response plus the "device identification" VPD page (i.e. the first related sdparm option). The second related sdparm option expands the decoding of the standard INQUIRY response.
-K1	--save	keep_features_over_reset is a global flag in ATA but per field in SCSI. Hence not an exact match.
-L0	--command=unlock	unlock door of removable media
-S <n>	--set SCT=<m>	Standby condition timer, <n> has 5 second units (roughly) while <m> has 100 ms units
-W0	--set WCE=0	disable write cache
-W1	--set WCE=1	enable write cache
-y	--command=stop	places an ATA disk, or a CD/DVD drive, in standby mode

As noted in an earlier section, even though sdparm can fetch the response to an ATA IDENTIFY (PACKET) DEVICE command (with '--page=ai' to get the ATA information VPD page), it dumps it in hex, only decoding the device identification strings. The hdparm utility does decode it when its '-I' option is used. The hdparm utility can also accept response data from stdin as long as it has a specific format (which is the format seen with 'cat /proc/ide/hd<x>/identify') when the '--Istdin' option is given. See the earlier SATA section for more details.

Note that hdparm version 7.3 and later (currently at version 7.7) can detect a SATL. This yields a more direct way to decode the ATA IDENTIFY (PACKET) DEVICE command response and set features. For example 'hdparm -I /dev/sda' should work if /dev/sda is a SATA disk or a S-ATAPI device (e.g. a CD/DVD drive).

FreeBSD

Version 0.97 has been ported to the FreeBSD operating system. Virtually all of sdparm's features work with FreeBSD. SCSI commands are routed through the CAM pass-through interface. The author tested sdparm with FreeBSD version 6.1 and found SCSI disks worked with the "da" device (e.g. 'sdparm /dev/da0'). SCSI tape drives can be accessed via the "sa" device via /dev nodes starting with "esa", "nsa" and "sa". To access cd/dvd drives, the kernel needs to be build with the "atapicam" device after which access is via the "cd" device. Other SCSI devices are "ses" (for enclosure services), "ch" (media changer (for tapes)), and "pr" for processor device type (e.g. SAF-TE devices). All these device may also be accessed via the "pass" device. To see the mapping between the "pass" device name and the corresponding higher level device node try "camcontrol devlist".

Solaris

Version 1.02 has been ported to Solaris. The "uscsi" SCSI pass-through interface is used.

Tru64

An experimental port to Tru64 (OSF) was added in version 0.97 .

Windows

This port was first added in sdparm version 1.00 . Only Windows NT, 2000, 2003 and XP are supported (it also worked on Vista RC1). The Microsoft SCSI Pass Through (SPT) interface is used (i.e. the Adaptec aspi32 dll is not required). The Windows version has a '--wscan' option which scans for devices, attempting to list one device per line. On each line are the various device names (i.e. SCSI name, (first) volume name and class driver name) with the INQUIRY response strings to the right. Here is an example:
# sdparm --wscan
SCSI0:0,0,0       C:    PD0      IC25N040ATCS05-0        CS4O *
SCSI1:0,0,0       D:    CDROM0   HITACHI DVD-ROM GD-S200 0034
SCSI2:0,0,0       I: + PD5      QUANTUM LPS525S         3110
SCSI2:0,6,0             TAPE0    SONY    SDT-7000        0192
                  E:             Generic USB SD Reader   1.00 pdt=0
                        PD1      Generic USB SD Reader   1.00

The "PD<n>" notation is shorthand for "PhysicalDrive<n>" which is the name passed to OS interface calls. The "+" after the "I:" volume name indicates that other volumes (partitions) are on that drive. In this case the device name that sdparm will accept for the Quantum drive are "I:", "J:", "PD5" or "PhysicalDrive5". Windows will not allow the "SCSI2:0,0,0" form to be used when a class driver name is available ("PD5" in this case). The "*" at the end of the first line indicates that the INQUIRY data provided by Windows was not quite correct and that usually indicates that the disk is an ATA device. The last two lines reflect a shortcoming of the current scan logic as they represent the same USB drive.

The sdparm package can be built in either a cygwin or MinGW environment. The cygwin environment produces an executable that depends on cygwin1.dll which needs to be obtained separately (it is free as the sdparm package is open source). The MinGW environment (and its MSYS shell) produces freestanding console applications. The executables produced in either environment can run in a cygwin, MSYS or "cmd" shell.

Examples

These examples use Linux device names. Examples of appropriate device name for some other ports of sdparm are:

FreeBSD: /dev/da0 and /dev/pass0
Solaris: /dev/rsdk/c5t4d2s2 or /dev/rsdk/c5t4d2p0
Windows: PD1, D: and CDROM0

List the common (mode) parameters of a disk:
# sdparm /dev/sda
    /dev/sda: SEAGATE ST336732LC        ABCD
Read write error recovery mode page:
AWRE        1 [cha: y, def: 1, sav: 1]
ARRE        1 [cha: y, def: 1, sav: 1]
PER         0 [cha: y, def: 0, sav: 0]
Caching (SBC) mode page:
WCE         0 [cha: y, def: 0, sav: 0]
RCD         0 [cha: y, def: 0, sav: 0]
Control mode page:
SWP         0 [cha: n, def: 0, sav: 0]
Informational exceptions control mode page:
EWASC       1 [cha: y, def: 1, sav: 1]
DEXCPT      0 [cha: y, def: 0, sav: 0]
MRIE        4 [cha: y, def: 2, sav: 4]

List the descriptors within the device identification VPD page of a disk. [VPD pages are fetched with the SCSI INQUIRY command.]:
# sdparm --inquiry /dev/sdb
    /dev/sdb: SEAGATE   ST336754SS        0003
Device identification VPD page:
Addressed logical unit:
    desig_type: NAA, code_set: Binary
      0x5000c50000520a2b
Target port:
    desig_type: NAA, code_set: Binary
     transport: Serial Attached SCSI (SAS)
      0x5000c50000520a2a
    desig_type: Relative target port, code_set: Binary
     transport: Serial Attached SCSI (SAS)
      Relative target port: 0x2
Target device that contains addressed lu:
    desig_type: NAA, code_set: Binary
     transport: Serial Attached SCSI (SAS)
      0x5000c50000520a28
    desig_type: SCSI name string, code_set: UTF-8
     transport: Serial Attached SCSI (SAS)
      SCSI name string:
      naa.5000C50000520A28

To trim down that output, add the '--quiet' option:
# sdparm --inquiry --quiet /dev/sdb
0x5000c50000520a2b
0x5000c50000520a2a
0x5000c50000520a28
naa.5000C50000520A28

See all parameters for the read write error recovery mode page:
# sdparm --page=rw /dev/sda
    /dev/sda: SEAGATE   ST336732LC        ABCD
Read write error recovery mode page:
AWRE        1 [cha: y, def: 1, sav: 1]
ARRE        1 [cha: y, def: 1, sav: 1]
TB          0 [cha: y, def: 0, sav: 0]
RC          0 [cha: y, def: 0, sav: 0]
EER         0 [cha: y, def: 0, sav: 0]
PER         0 [cha: y, def: 0, sav: 0]
DTE         0 [cha: y, def: 0, sav: 0]
DCR         0 [cha: y, def: 0, sav: 0]
RRC        11 [cha: y, def: 11, sav: 11]
COR_S     240 [cha: n, def:240, sav:240]
HOC         0 [cha: n, def: 0, sav: 0]
DSOC        0 [cha: n, def: 0, sav: 0]
WRC         5 [cha: y, def: 5, sav: 5]
RTL        -1 [cha: y, def: -1, sav: -1]

See all parameters for the read write error recovery mode page with acronym descriptions:
# sdparm --page=rw --long /dev/sda
    /dev/sda: SEAGATE ST336732LC        ABCD
    Direct access device specific parameters: WP=0 DPOFUA=1
Read write error recovery mode page:
AWRE        1 [cha: y, def: 1, sav: 1] Automatic write reallocation enabled
ARRE        1 [cha: y, def: 1, sav: 1] Automatic read reallocation enabled
TB          0 [cha: y, def: 0, sav: 0] Transfer block
RC          0 [cha: y, def: 0, sav: 0] Read continuous
EER         0 [cha: y, def: 0, sav: 0] Enable early recovery
PER         0 [cha: y, def: 0, sav: 0] Post error
DTE         0 [cha: y, def: 0, sav: 0] Data terminate on error
DCR         0 [cha: y, def: 0, sav: 0] Disable correction
RRC        11 [cha: y, def: 11, sav: 11] Read retry count
COR_S     240 [cha: n, def:240, sav:240] Correction span (obsolete)
HOC         0 [cha: n, def: 0, sav: 0] Head offset count (obsolete)
DSOC        0 [cha: n, def: 0, sav: 0] Data strobe offset count (obsolete)
WRC         5 [cha: y, def: 5, sav: 5] Write retry count
RTL        -1 [cha: y, def: -1, sav: -1] Recovery time limit (ms)

The '--long' option can be used twice to get more information on selected mode page field values. The next example uses the '--enumerate' option so that tables within sdparm are being probed (rather than a specific DEVICE):
# sdparm --enumerate --page=ie --long --long
Informational exceptions control [0x1c] mode page:
PERF       [0x02:7:1 ] Performance
EBF        [0x02:5:1 ] Enable background function
EWASC      [0x02:4:1 ] Enable warning
DEXCPT     [0x02:3:1 ] Disable exceptions
TEST       [0x02:2:1 ] Test (simulate device failure)
EBACKERR   [0x02:1:1 ] Enable background error reporting
LOGERR     [0x02:0:1 ] Log informational exception errors
MRIE       [0x03:3:4 ] Method of reporting informational exceptions
        0: no reporting; 1: async reporting; 2: unit attention
        3: conditional recovered error; 4: recovered error
        5: check condition with no sense; 6: request sense only
INTT       [0x04:7:32] Interval timer (100 ms)
REPC       [0x08:7:32] Report count

The short option form of the above invocation would be 'sdparm -ell -p ie'. Notice that the MRIE field has its possible values listed on the next, tab indented, lines. Only fields with non-obvious values supply this extra information.

To get the Writeback Cache Enable (WCE) values from the caching control mode page:
# sdparm --get=WCE /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD
WCE         0 [cha: y, def: 1, sav: 0]

Get the Write Cache Enable (WCE) values from the caching control mode page in hex (using short option form). The four values are the current value, the changeable mask, the default value and the saved value respectively:
# sdparm -g WCE -H /dev/sdd
0x00 0x01 0x01 0x00

Get the Write Cache Enable (WCE) current value from the caching control mode page in hex:
# sdparm -g WCE=1 -H /dev/sdd
0x00

Set the "write cache enable" current value in the caching control mode page. Note that only INQUIRY identification information is output; if an error occurs then more information is output (and the sdparm process completes with a non-zero exit status):
# sdparm --set=WCE /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD

Check that change occurred (and suppress the disk identification line with '--quiet'):
# sdparm --get=WCE --quiet /dev/sdd
WCE         1 [cha: y, def: 1, sav: 0]

Change both the current and saved values of the WCE field:
# sdparm --set=WCE --save /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD

Check that saved value has also changed:
# sdparm --get=WCE /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD
WCE         1 [cha: y, def: 1, sav: 1]

Multiple fields in the same mode page can be changed (set WCE and clear RCD):
# sdparm --set=WCE --clear=RCD --save /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD

The previous example can also be written as:
# sdparm -s WCE=1,RCD=0 -S /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD

Set the caching mode page to its default values (copy defaults into current and saved values):
# sdparm --page=ca --defaults --save /dev/sdd
    /dev/sdd: SEAGATE ST373453LC        ABCD

One disk vendor has a "performance mode" bit (PM) in the vendor specific unit attention mode page [0x0,0x0]. PM=0 is server mode (the default) while PM=1 is desktop mode. Desktop mode can be set (both current and saved values) with:
# sdparm --page=0 --set=2:7:1=1 --save --quiet /dev/sdd

Since there are no acronyms defined for the unit attention mode page, its fields can be viewed in hex. The above command causes the top bit in byte 2 of the current and saved values to be set:
# sdparm --page=0 --hex /dev/sdd
mode page 0x0:
    Current:
00     80 06 80 00 0f 00 00 00
    Changeable:
00     80 06 f7 40 0f 00 00 00
    Default:
00     80 06 00 00 0f 00 00 00
    Saved:
00     80 06 80 00 0f 00 00 00

So where acronyms are available, values can be fetched and set in a relatively straight forward manner. In the absence of acronyms, the lower level numeric descriptors can be used. Here is an example of using a numeric descriptor to set the single bit at bit position 7 in byte 2 in mode page 0 to the value 1. The corresponding saved value is also set:

sdparm --page=0 --set=2:7:1=1 --save /dev/sda

Here is an example of common transport parameters fetched from a SAS disk. The '--long' option adds a description of each field to the right:

# sdparm --transport=sas --long /dev/sdc
    /dev/sdc: TESTING XY777701SS        ABCD
    Direct access device specific parameters: WP=0 DPOFUA=1
Disconnect-reconnect (SAS) [dr] mode page:
BITL        0 [cha: n, def: 0, sav: 0] Bus inactivity time limit (100us)
MCTL        0 [cha: n, def: 0, sav: 0] Maximum connect time limit (100us)
MBS       314 [cha: y, def:314, sav:314] Maximum burst size (512 bytes)
Protocol specific logical unit (SAS) [p1] mode page:
LUPID       6 [cha: n, def: 6, sav: 6] Logical unit's (transport) protocol identifier
Protocol specific port (SAS) [pp] mode page:
PPID        6 [cha: n, def: 6, sav: 6] Port's (transport) protocol identifier
BAE         0 [cha: n, def: 0, sav: 0] Broadcast asynchronous event
RLM         0 [cha: y, def: 0, sav: 0] Ready LED meaning
ITNLT     2000 [cha: y, def:2000, sav:2000] I_T nexus loss time (ms)
IRT       10000 [cha: y, def: 0, sav:10000] Initiator response timeout (ms)
Phy control and discover (SAS) [pcd] mode page:
NOP         2 [cha: n, def: 2, sav: 2] Number of phys

Say we want to look closer at the SAS "phy control and discover" mode page. It has variable length with a header portion (containing PPID_1, GENC, and NOP) followed by two descriptors (as indicated by the current value of NOP). The first descriptor (which could have the ".0" extension but it is not displayed on output) ranges from PHID to HMALR inclusive. The second descriptor has the ".1" suffix:

# sdparm -t sas -p pcd -l /dev/sdb    /dev/sdb: SEAGATE   ST32000444SS      0006    Direct access device specific parameters: WP=0 DPOFUA=1Phy control and discover (SAS) [pcd] mode page: PPID_1      6 [cha: n, def: 6, sav: 6] Port's (transport) protocol identifier GENC        0 [cha: n, def: 0, sav: 0] Generation code NOP         2 [cha: n, def: 2, sav: 2] Number of phys PHID        0 [cha: n, def: 0, sav: 0] Phy identifier ADT         2 [cha: n, def: 2, sav: 2] Attached device type AREAS       3 [cha: n, def: 3, sav: 3] Attached reason (other end did link reset) REAS        1 [cha: n, def: 1, sav: 1] Reason (for starting link reset) NPLR       10 [cha: n, def: 10, sav: 10] Negotiated logical link rate ASIP        0 [cha: n, def: 0, sav: 0] Attached SSP initiator port ATIP        0 [cha: n, def: 0, sav: 0] Attached STP initiator port AMIP        0 [cha: n, def: 0, sav: 0] Attached SMP initiator port ASTP        0 [cha: n, def: 0, sav: 0] Attached SSP target port ATTP        0 [cha: n, def: 0, sav: 0] Attached STP target port AMTP        1 [cha: n, def: 1, sav: 1] Attached SMP target port SASA      0x5000c500215725bd [cha: n, def:0x5000c500215725bd, sav:0x5000c500215725bd] SAS address ASASA     0x5001517e85c3efff [cha: n, def:0x5001517e85c3efff, sav:0x5001517e85c3efff] Attached SAS address APHID      21 [cha: n, def: 21, sav: 21] Attached phy identifier APOWCAP     0 [cha: n, def: 0, sav: 0] Attached power capable ASLCAP      0 [cha: n, def: 0, sav: 0] Attached slumber capable APACAP      0 [cha: n, def: 0, sav: 0] Attached partial capable AIZPER      0 [cha: n, def: 0, sav: 0] Attached inside ZPSDS persistent AREQIZ      0 [cha: n, def: 0, sav: 0] Attached request inside ZPSDS ABRCAP      0 [cha: n, def: 0, sav: 0] Attached break reply capable PMILR       8 [cha: y, def: 8, sav: 8] Programmed minimum link rate HMILR       8 [cha: n, def: 8, sav: 8] Hardware minimum link rate PMALR      10 [cha: y, def: 10, sav: 10] Programmed maximum link rate HMALR      10 [cha: n, def: 10, sav: 10] Hardware maximum link rate PHID.1      1 [cha: n, def: 1, sav: 1] Phy identifier ADT.1       0 [cha: n, def: 0, sav: 0] Attached device type AREAS.1     0 [cha: n, def: 0, sav: 0] Attached reason (other end did link reset) REAS.1      0 [cha: n, def: 0, sav: 0] Reason (for starting link reset) NPLR.1      0 [cha: n, def: 0, sav: 0] Negotiated logical link rate ASIP.1      0 [cha: n, def: 0, sav: 0] Attached SSP initiator port ATIP.1      0 [cha: n, def: 0, sav: 0] Attached STP initiator port AMIP.1      0 [cha: n, def: 0, sav: 0] Attached SMP initiator port ASTP.1      0 [cha: n, def: 0, sav: 0] Attached SSP target port ATTP.1      0 [cha: n, def: 0, sav: 0] Attached STP target port AMTP.1      0 [cha: n, def: 0, sav: 0] Attached SMP target port SASA.1    0x5000c500215725be [cha: n, def:0x5000c500215725be, sav:0x5000c500215725be] SAS address ASASA.1   0x0 [cha: n, def:0x0, sav:0x0] Attached SAS address APHID.1     0 [cha: n, def: 0, sav: 0] Attached phy identifier APOWCAP.1   0 [cha: n, def: 0, sav: 0] Attached power capable ASLCAP.1    0 [cha: n, def: 0, sav: 0] Attached slumber capable APACAP.1    0 [cha: n, def: 0, sav: 0] Attached partial capable AIZPER.1    0 [cha: n, def: 0, sav: 0] Attached inside ZPSDS persistent AREQIZ.1    0 [cha: n, def: 0, sav: 0] Attached request inside ZPSDS ABRCAP.1    0 [cha: n, def: 0, sav: 0] Attached break reply capable PMILR.1     8 [cha: y, def: 8, sav: 8] Programmed minimum link rate HMILR.1     8 [cha: n, def: 8, sav: 8] Hardware minimum link rate PMALR.1    10 [cha: y, def: 10, sav: 10] Programmed maximum link rate HMALR.1    10 [cha: n, def: 10, sav: 10] Hardware maximum link rate

The '--long' with '--enumerate' options on a mode page that can have descriptors appends descriptor format information after the fields. The SAS phy control and discovery mode page can have descriptors (one for each phy). A '--transport=sas' option is not required (from version 1.02 onwards) because "pcd" doesn't match any generic mode page (or VPD page) abbreviation, so SAS mode page abbreviations are checked and a match is found.
# sdparm --enumerate --page=pcd --long
Phy control and discover (SAS) [pcd: 0x19,0x1] mode page:
PPID_1     [0x05:3:4 ] Port's (transport) protocol identifier
GENC       [0x06:7:8 ] Generation code
NOP        [0x07:7:8 ] Number of phys
PHID       [0x09:7:8 ] Phy identifier
ADT        [0x0c:6:3 ] Attached device type
AREAS      [0x0c:3:4 ] Attached reason (other end did link reset)
REAS       [0x0d:7:4 ] Reason (for starting link reset)
NPLR       [0x0d:3:4 ] Negotiated logical link rate
ASIP       [0x0e:3:1 ] Attached SSP initiator port
ATIP       [0x0e:2:1 ] Attached STP initiator port
AMIP       [0x0e:1:1 ] Attached SMP initiator port
ASTP       [0x0f:3:1 ] Attached SSP target port
ATTP       [0x0f:2:1 ] Attached STP target port
AMTP       [0x0f:1:1 ] Attached SMP target port
SASA       [0x10:7:64] SAS address
ASASA      [0x18:7:64] Attached SAS address
APHID      [0x20:7:8 ] Attached phy identifier
APOWCAP    [0x21:6:2 ] Attached power capable
ASLCAP     [0x21:4:1 ] Attached slumber capable
APACAP     [0x21:3:1 ] Attached partial capable
AIZPER     [0x21:2:1 ] Attached inside ZPSDS persistent
AREQIZ     [0x21:1:1 ] Attached request inside ZPSDS
ABRCAP     [0x21:0:1 ] Attached break reply capable
PMILR      [0x28:7:4 ] Programmed minimum link rate
HMILR      [0x28:3:4 ] Hardware minimum link rate
PMALR      [0x29:7:4 ] Programmed maximum link rate
HMALR      [0x29:3:4 ] Hardware maximum link rate
<<SAS phy mode descriptor>>
    num_descs_off=7, num_descs_bytes=1, num_descs_inc=0, first_desc_off=8
    descriptor_len=48

Here is a command example; for ejecting a DVD from a drive:

# sdparm --command=eject /dev/hdc
    /dev/hdc: HITACHI   DVD-ROM GD-S200   0034 [pdt=0x5]
# echo $?
0

The process status of 0 indicates that the eject command succeeded.

Downloads and build

The initial version of sdparm was 0.90 .

**Table 2. sdparm tarballs, rpm + deb packages**
version release date	tarball	i386 + x64 rpm binary **	debian package	Windows exe 32 bit unless noted
0.90 20050418	sdparm-0.90.tgz	sdparm-0.90-1.i386.rpm	sdparm_0.90-2_i386.deb
0.91	sdparm-0.91.tgz	sdparm-0.91-1.i386.rpm	sdparm_0.91-2_i386.deb
0.92	sdparm-0.92.tgz	sdparm-0.92-1.i386.rpm	sdparm_0.92-2_i386.deb
0.93	sdparm-0.93.tgz	sdparm-0.93-1.i386.rpm	sdparm_0.93-2_i386.deb
0.94	sdparm-0.94.tgz	sdparm-0.94-1.i386.rpm	sdparm_0.94-2_i386.deb
0.95	sdparm-0.95.tgz	sdparm-0.95-1.i386.rpm	sdparm_0.95-0.1_i386.deb
0.96	sdparm-0.96.tgz	sdparm-0.96-1.i386.rpm	sdparm_0.96-0.1_i386.deb
0.97	sdparm-0.97.tgz	sdparm-0.97-1.i386.rpm	sdparm_0.97-0.1_i386.deb
0.98	sdparm-0.98.tgz	sdparm-0.98-1.i386.rpm	sdparm_0.98-0.1_i386.deb
0.99	sdparm-0.99.tgz	sdparm-0.99-1.i386.rpm	sdparm_0.99-0.1_i386.deb
1.00 20061016	sdparm-1.00.tgz	sdparm-1.00-1.i386.rpm	sdparm_1.00-0.1_i386.deb
1.01 20070405	sdparm-1.01.tgz	sdparm-1.01-1.i386.rpm	sdparm_1.01-0.1_i386.deb	sdparm101.exe
1.02 20071008	sdparm-1.02.tgz	sdparm-1.02-1.i386.rpm	sdparm_1.02-0.1_i386.deb	sdparm102.exe
1.03 20080623	sdparm-1.03.tgz	sdparm-1.03-1.i386.rpm	sdparm_1.03-0.1_i386.deb	sdparm103.exe
1.04 20090920	sdparm-1.04.tgz	sdparm-1.04-1.i386.rpm	sdparm_1.04-0.1_i386.deb	sdparm104.exe
1.05 20100413	sdparm-1.05.tgz	sdparm-1.05-1.i386.rpm sg3_utils-libs-1.29-1.i386.rpm	sdparm_1.05-0.1_i386.deb libsgutils2-2_1.29-0.1_i386.deb	sdparm105.exe
1.06 20101111	sdparm-1.06.tgz	sdparm-1.06-1.i386.rpm sg3_utils-libs-1.30-1.i386.rpm	sdparm_1.06-0.1_i386.deb libsgutils2-2_1.30-0.1_i386.deb	sdparm.exe
1.07 20120121	sdparm-1.07.tgz	sdparm-1.07-1.i386.rpm [built without sgutils lib dependency]	sdparm_1.07-0.1_i386.deb [built without sgutils lib dependency]	sdparm.exe
1.08 20130606	sdparm-1.08.tgz sdparm-1.08.tar.xz	sdparm-1.08-1.i386.rpm sdparm-1.08-1.x86_64.rpm [built without sgutils lib dependency]	sdparm_1.08-0.1_i386.deb sdparm_1.08-0.1_amd64.deb [built without sgutils lib dependency]	sdparm.exe
1.09 21401226	sdparm-1.09.tgz sdparm-1.09.tar.xz	sdparm-1.09-1.i386.rpm sdparm-1.09-1.x86_64.rpm [built without sgutils lib dependency]	sdparm_1.09-0.1_i386.deb sdparm_1.09-0.1_amd64.deb [built without sgutils lib dependency]	sdparm.exe sdparm_64.exe
1.10 20160222	sdparm-1.10.tgz sdparm-1.10.tar.xz	sdparm-1.10-1.i386.rpm sdparm-1.10-1.x86_64.rpm [built without sgutils lib dependency]	sdparm_1.10-0.1_i386.deb sdparm_1.10-0.1_amd64.deb [built without sgutils lib dependency]	sdparm.exe sdparm_64.exe

The tarball contains an "rpm" spec file which is used to build source rpm and the i386 binary rpm. The alien utility was used to build the "deb" package from the i386 binary rpm up till version 0.94 . Later versions have debian package build infrastructure. The Windows ".exe" was built on Vista with MinGW. Here is the ChangeLog .

The sdparm "man" page is online: sdparm.8.html .

sdparm version 1.05 and later may depend on the libsgutils shared library. The sdparm 1.05 tarball contains extra source code so that it can build the executable without depending on libsgutils. However if the libsgutils library is present (more precisely the "dev" component of that library) during the build of sdparm then the executable will depend on libsgutils. In Unix the 'ldd sdparm' command will show which shared libraries that sdparm depends on.

The sdparm tarball contains source code and build scripts that support the './configure ; make ; make install' pattern. In some environments the ./autogen.sh script may need to be run prior to ./configure . Many options can be given to ./configure and ./configure --help will list many of those options. For example './configure --prefix=/usr ; make ; make install' should build sdparm so that it installs the executable at /usr/bin/sdparm (the default install location is /usr/local/bin/sdparm ).

** Some browsers (e.g. firefox) may interpret a file with an extension of "rpm" as an audio file. In which case press the right button over the link and select "Save link as ..." to download the file.

To do

The author hopes a GUI wrapping this utility (or using it as a library) will emerge. SCSI mode pages especially lend themselves to a GUI representation similar to the table representations found in the SCSI (draft) standards and vendors' product manuals.

Return to main page.

Last updated: 22nd February 2016