The sdparm utility



The sdparm utility

Introduction

SCSI mode pages

VPD pages

sdparm commands

sdparm syntax

Exit status

Transports

USB

IEEE 1394

SATA

NVME

Vendor specific mode pages

Supported operating systems

Linux

hdparm mapping

FreeBSD

Solaris

Tru64

Windows

Examples

Downloads and build

To do

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.12 . 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:

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:

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):

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:

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='.

--examine

-E

probes all mode or VPD pages. For mode pages only those with known field names are probed when the --all option is given. For VPD pages only those pages listed in "Supported VPD pages page" are decoded. In both cases some pages may be missed.

--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.

--out-mask=OM

-o OM

the value OM (default decimal) selects whether current (0x1), changeable (0x2), default (0x4) and/or saveable (0x8) values are output. The default is 0xf (i.e. 0x1|0x2|0x4|0x8).

--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:

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:

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:

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:

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.

NVME

There is experimental support for NVMe disks in release 1.12 . Only the NVMe equivalent of WCE (write cache enable) can be set or cleared.

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:

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=1
Phy 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

1.11

20200303

sdparm-1.11.tgz
sdparm-1.11.tar.xz

sdparm-1.11-1.x86_64.rpm

sdparm_1.11-0.1_amd64.deb


1.12

20210421

sdparm-1.12.tgz
sdparm-1.12.tar.xz

sdparm-1.12-1.x86_64.rpm

sdparm_1.12-0.1_i386.deb

sdparm_1.12-0.1_amd64.deb



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: 23rd April 2021