The sdparm utility

Introduction

The sdparm utility outputs and in some cases modifies SCSI device parameters. When the SCSI device is a disk, sdparm's role is similar to its namesake: the Linux hdparm utility which is for ATA disks that usually have device names starting with "hd". More generally sdparm can be used to output and modify 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.

The information in this page corresponds to sdparm version 1.01 .

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 connected directly 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-5. This diagram shows how various SCSI and associated standards interrelate. Often device product manuals detail precisely which mode pages (and parts thereof) are supported by a particular model and 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 20 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 or 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.

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.

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. In many cases these acronyms 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 (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).

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.

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 (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, so often disks 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.

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)

If a VPD page other than from the above list is requested (e.g. '--page=82h') and the device gives a response then that response it output in ASCII hex. VPD page abbreviations can be listed with 'sdparm --enumerate --inquiry'.

The sg3_utils package (from version 1.21 onwards) 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
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)
start: spin up the medium
stop: spin down the medium
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.

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 given device while the other commands need both read and write permissions.

sdparm syntax

sdparm is a command line utility which takes zero or more options usually followed by a device name. Only invocations that use the '--enumerate' 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 SCSI 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.
--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).
--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").
--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.
--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
--vendor=<vn>	-M <vn>	vendor (manufacturer) identifier; either a number or an abbreviation (e.g. "sea" or "hit") can be given
--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.

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.

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.
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.
15 sdparm is unable to open, close or use the given device. The given file name could be incorrect or there may be permission problems. Adding the '-v' option may give more information.
20 the <scsi_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.
33 the command sent to the device has timed out.
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.

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 correspond to the SCSI sense key values that they correspond to.

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.

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

USB is an important transport for mass storage but little is said about it in the "SCSI" standards at t10.org . Specifications 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 an 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 in the author's experience the translation is minimal. 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 lk 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. Features such as locking and password based access control are being discussed for USB so there may be improvements in the future.

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 is an emerging 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 draft 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 current version of hdparm this sequence may be more stable: 'sdparm --page=ai -HHH /dev/sda > t ; hdparm --Istdin < t' .

The SAT draft only defines a few attributes 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 attributes.

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 has (and sdparm has table for) use something like 'sdparm -e -M sea'. Getting, setting and clearing mode page attributes follows 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 attributes 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 reasonable 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 attribute. These attributes can be looked up in the "man page" for hdparm. The sdparm utility uses more generic command line options with acronyms for attributes; 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 attributes 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 attributes 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 recognised 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) attribute 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 attribute 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 IDENTIFY (PACKET) DEVICE ATA 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.

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

Tru64

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

Windows

This port was first added in version 1.00 . Only Windows NT, 2000, 2003 and XP are supported. The Microsoft SCSI Pass Through interface is used (i.e. the Adaptec aspi32 dll is not required). There is a '--wscan' option (Windows only) which scans for devices, attempting to list one device per line. On that 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:" or "PD5" plus several longer forms. 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 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 sg3_utils package can be built in either a cygwin or MinGW environment. The cygwin environment produces executables that depend on cygwin1.dll which needs to be obtained separately (it is free as the sg3_utils 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. Simply use device names appropriate to the Operating System for other ports of sdparm.

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 attribute 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 common transport parameters fetched from a SAS disk:
# sdparm --transport=sas /dev/sdb
    /dev/sdb: TESTING   XY777701SS        ABCD
Disconnect-reconnect (SAS) mode page:
BITL        0 [cha: n, def: 0, sav: 0]
MCTL        0 [cha: n, def: 0, sav: 0]
MBS       164 [cha: y, def:164, sav:164]
lu: SSP short format (SAS) mode page:
LUPID       6 [cha: n, def: 6, sav: 6]
port: SSP short format (SAS) mode page:
PPID        6 [cha: n, def: 6, sav: 6]
RLM         0 [cha: y, def: 0, sav: 0]
ITNLT     2000 [cha: y, def:2000, sav:2000]
IRT         0 [cha: y, def: 0, sav: 0]
port: phy control and discover (SAS) mode page:
NOP         2 [cha: n, def: 2, sav: 2]

Here is a command example; ejecting a CD:
# 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

The initial version of sdparm was 0.90 .

**Table 2. sdparm tarballs, rpm + deb packages**
version	tarball	i386 rpm binary **	debian package	Windows exe
0.90	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	sdparm-1.00.tgz	sdparm-1.00-1.i386.rpm	sdparm_1.00-0.1_i386.deb
1.01 beta	sdparm-1.01.tgz			sdparm.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 (see INSTALL). The Windows ".exe" was built on Windows 2000 with MinGW. Here is the ChangeLog .

** 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: 1st December 2006