tw_cli(8) - 3ware Storage Controller Management Command Line Interface
(CLI) manpage / HTML Help Dcoument Version 3.0.
tw_cli Interactive Mode tw_cli -f file Process from a file tw_cli command Process single command (batch mode)
tw_cli(8) is a Command Line Interface Storage Management Software for 3ware ATA RAID Controller(s). It provides controller, logical unit and drive management. tw_cli can be used in both interactive and batch mode, providing higher-level API (Application Programming Interface) functionalities.
The CLI prompt indicates the current object in focus, expressed in URI (Universal Resource Identifier) syntax consisting of a hostname (//hostname), and an object path (/path/path/object) such as //elvis/c0/u0. User can set the focus to a particular object by focus URI.
CLI also supports comments. Command lines beginning with # denotes start of comment. This feature is mostly useful with batch processing via -f script flag.
CLI uses the following terminology:
Logical Units. Usually shortened to "units", these are block devices presented to the operating system. A logical unit can be a one-tier, two-tier, or three-tier arrangement. Spare and Single logical units are examples of one-tier units. RAID-1 and RAID-5 are examples of two-tier units and as such will have sub-units. RAID-10 and RAID-50 are examples of three-tier units and as such will have sub-sub-units.
Port. 3ware controller models up to the 9650SE series have one or many ports (typically 4, 8, 12, 16, or 24). Each port can be attached to a single disk drive. On a controller such as the 9650SE with a multilane serial port connector, one connector supports four ports. On the 9690SA and 9750 controllers, connections are made with phys and vports (virtual ports).
Phy. Phys are tranceivers that transmit and receive the serial data stream that flows between the controller and the drives. The 9690SA controller have 8 phys. These "controller phys" are associated with virtual ports (vports) to establish up to 128 potential connections with the SAS or SATA drives. Each controller phy can be connected to a single drive, or can be connected through an expander to additional drives.
VPort. Connections from the 9690SA and 9750 controllers to drives are referred to as virtual ports, or vports. A vport indicates the ID of a drive, whether it is directly connected to the controller, or cascaded through one of more expanders. The vport, in essense, is a handle in the software to uniquely identify a drive. The port ID or vport ID allows a drive to be consistently identified, used and managed in a RAID unit. For dual-ported drives, although there are two connections to a drive, the drive is still identified with one vport handle. Note: With the controller summay via the command "show", the number of (V)Ports shown may contain two times (2X) the number of drives (suggesting the dual-ported drive type) even though the (V)Port column of the summary to the command "/cx show" contains only the number of vports corresponding to the number of drives. This is because the drive is identified with only one vport handle.
NOTE: For all practical purposes, hereafter port and vport are used interchangeably in reference to a drive (or disk). Therefore, unless otherwise specified, the mention of port implies vport as well. That is, while "port" is mentioned to denote a drive, it is implied that for the applicable controller series, the reference also applies to vport.
CLI supports a set of primary command syntax and a set of legacy command syntax that is the old or original command syntax. Note: The primary command syntax replaces that legacy command syntax and as such support for legacy commands will discontinue in the near future.
Please also note that some of the commands listed in this document are qualified with restrictions of controller type/model support. For example, "9000 series" or "9550SX and higher" may be next to a command. The following is a summary of the controller qualified specifications.
Commands with:
No specifications Could be used across all controller platforms. This includes
the 7000 and 8000 series controllers.
9000 series Could be used in all controllers in the 9000 series. This
excludes the 7000 and 8000 series controllers, and includes
the 9550SX, 9590SE, 9650SE, 9690SA and 9750 controllers.
9550SX and higher For controller models 9550SX, 9650SE, 9690SA and 9750.
9650SE and higher For controller models 9650SE, 9690SA and 9750.
For the Mac system, while still true, the command qualifier is not meaningful as all commmands are supported, provided the controller model is 9590SE or 9650SE (or above).
Here is a summary of the controllers and their associated support:
Controller | Added Support
----------------+-------------------------------------------
7000 / 8000 | JBOD
----------------+-------------------------------------------
9500S | JBOD
----------------+-------------------------------------------
9550SX | PCI-X 133
----------------+-------------------------------------------
9590SE | bridge / PCI express
----------------+-------------------------------------------
9650SE | PCI express, RAID 6, enclosure services,
| AMI 9071/2 chipset, CCU
----------------+-------------------------------------------
9690SA | SAS, SES-2, enclosure services, No CCU,
| JBOD support in stealth mode
----------------+-------------------------------------------
9750 | phy link capability of 6.0 Gpbs added
| for SAS drives
----------------+-------------------------------------------
Please note that the support items are accumulative down the list, excepted where noted. Also, CCU (Chassis Control Unit) refers to the JMR enclosure/Sidecar.
This document organizes the CLI command set as different types of Object Messages, and descriptions and examples are presented for each object message or command. While some of the system features could be invoked with one "set" command and correspondingly displayed with a "show" command and as such, information regarding the feature may be self-contained within the description of the set command, other features may require or involve a set of commands that work together and may not be so straight-forward. For these, the command descriptions may present a fragmented view of the feature as a result. For an encapsulated view of certain features and their relevant command set, please see the Features section of this document.
This document, therefore, may be used as a reference for individual commands and also as a reference for supported features. For the former please see the Primary Command Syntax sections, and for the latter please see the Features sections.
The primary command syntax will replace the legacy command syntax in the future releases. The new and improved command format follows a general grammar in the form:
Object Message Attributes
Objects can be shell commands or can specify a controller, logical unit, port or vport (drive), or battery backup unit (bbu). Messages are commands sent to the requested objects. It may be a read operation such as for the command "show", or a write operation for the set, delete, add, stop, start, or remove commands. Attributes specify the values to read or write. Attributes are either Boolean Attributes or Named Attributes. Value of a Boolean attribute is deduced by presence. Value of named attributes are expressed in a "key = value" format.
Shell Object Messages are commands (a.k.a. methods/messages) that are sent to the Command Interpreter (a.k.a. Shell/CLI) itself.
This command shows a general summary of all detected controllers. Note that the appropriate kernel device drivers should be loaded for the list to show all controllers. The intention is to provide a global view of the environment.
Typical output looks like:
//localhost> show
Ctl Model Ports Drives Units NotOpt RRate VRate BBU -------------------------------------------------------------------------------- c0 7500-12 12 8 3 1 2 - - c1 9506S-12 12 6 1 0 3 5 TESTING
The output indicates that Controller 0 is a 7500 model with 12 Ports, with 8 Drives detected (attached), total of 3 Units, with one unit in a NotOpt (Not Optimal) state, a RRate(Rebuild Rate) of 2, VRate(Verify Rate) of '-' (Not Applicable), BBU of '-' (Not Applicable). Not Optimal refers to any state except OK and VERIFYING. Other states include INITIALIZING, INIT-PAUSED, REBUILDING, REBUILD-PAUSED, DEGRADED, MIGRATING, MIGRATE-PAUSED, RECOVERY, INOPERABLE, and UNKNOWN.
For a system with an enclosure unit as an attached expander, and the appropriate controller (9690SA), a global view of the environment includes summary information about detected enclosures. As example:
//localhost> show
Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU --------------------------------------------------------------------------- c0 G133e/Astor 12 4 1 0 1 1 -
Encl Slots Drives Fans TSUnits PSUnits -------------------------------------------------- /c0/e0 4 2 1 1 1
The enclosure summary information shows the name of the enclosure, and the number of elements within each element type that is part of the system as identified during discovery.
This command will show the CLI and API version.
For example:
//localhost> show ver CLI Version = 2.00.03.018 API Version = 2.01.00.004
This command shows the controller alarms or events, also known as AEN (Asynchronous Event Notification) messages, of all controllers in the system. The default display shows the most recent alarm at the end or bottom of the table. The reverse attribute reverses this order and shows the most recent alarm at the top of the table. For more information please see '/cx show AENs'.
This command shows the diagnostic information of all controllers in the system.
This command displays all rebuild schedules of all the 9000 controllers in the system.
This command displays all self test schedules of all the 9000 controllers in the system.
This command displays all verify schedules of all the 9000 controllers in the system.
This command iterates through all the controllers in the system and downloads the specified firmware image to the architecturally compatible controllers. Please refer to command /cx update fw=filename_with_path [force] for detail.
This command will set the specified object in focus. This command is active in interactive mode only and is provided to reduce typing. Recall that messages (or commands) are sent to objects such as
//hostname/c0/u0 show
Instead, if the focus is set to //hostname/c0/u0, the prompt is changed automatically to reflect this and the user would only have to type show. The concept is similar to being in a particular location in a file system and requesting a listing of the current directory.
object can have the following forms:
//hostname/cx/ux specifies the fully qualified URI of an object on host hostname, controller cx, unit ux.
//hostname specifies root of host hostname. The hostname is the name of the system where your 3ware RAID controllers are. With current releases, the hostname here should be always your system's name.
.. specifies one level up (the parent object).
/ specifies the root at the current focused host.
./obj specifies the next level of the object.
/c0/bbu specifies a relative path with respect to the current focused hostname.
For example:
//localhost> focus //elvis.3ware.com //elvis.3ware.com>
//elvis.3ware.com> focus /c0/u0 //elvis.3ware.com/c0/u0>
//elvis.3ware.com/c0/u0> focus .. //elvis.3ware.com/c0>
//elvis.3ware.com/c0> focus ./u0 //elvis.3ware.com/c0/u0>
//elvis.3ware.com/c0> focus / //elvis.3ware.com>
Note that focus is available as default. You can also set TW_CLI_INPUT_STYLE=OLD in the following to disable the feature.
If Bash, then "export TW_CLI_INPUT_STYLE=OLD" If csh, then "setenv TW_CLI_INPUT_STYLE OLD" If Windows, then "set TW_CLI_INPUT_STYLE=OLD"
Controller Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller such as /c0.
This command shows summary information on the specified controller /cx. This report consists of two to three parts: the Unit Summary that lists all units present, the Port Summary that lists the ports and disks attached to them, and if a BBU unit is installed, the BBU Summary that shows information on the BBU.
The Unit Summary section lists the units present with the unit number, unit type (such RAID 5), and unit status (such as OK, VERIFYING, INITIALIZING, etc.). The %RCompl reports the percent completion of the unit's Rebuild, if this task is in progress. The %V/I/M reports the percent completion of the unit's Verify, Initialize, or Migrate, if one of these are in progress. The stripe size, the usable capacity in gigabytes, the cache setting, and the autoverify setting are also listed.
Note: If a "*" appears at the end of the status, there is an error on one of the drives in the unit. Rescanning the controller will clear the error status if the condition no longer exists.
For controller models up to the 9550SX and 9650SE with Release 9.5.1 or earlier, the Port Summary section lists all present ports and for each port, the port number, drive status, unit affiliation, drive size (in blocks of 512 bytes), and the disk vendor assigned serial number are reported.
For the 9750, 9690SA and 9650SE controller with Release 9.5.2 or later, this section lists the ports or virtual ports present and for each port, the port or virtual port (VPort) number, drive status, unit affiliation, drive type, phy number (if direct attached), the enclosure and slot (if expander attached), and model number of the drive are reported.
Note: Unlike the 9550SX or older display, if a drive is not present, instead of showing the port with the status NOT-PRESENT with dashes ('-') across the columns in the summary table, for the 9750, 9690SA and 9650SE with Release 9.5.2 or later, that port entry is not listed. Thus, unlike the older display, the port numbers in this list may not be sequential. Moreover, if there are no drives present at all for the specified controller, the output of its Port Summary would show an empty summary consisting of only the header.
The BBU Summary section lists the online state, readiness, and status of the BBU unit, along with the voltage, temperature, charge capacity expressed as time remaining in hours, and the BBU's last test date.
Additional attributes about controllers, units, ports and disks can be obtained by querying for them directly. See other show sub-commands below.
Here is the typical output for controller models up to 9550SX and 9650SE with Release 9.5.1 or earlier:
//localhost> /c2 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 596.004 ON OFF u1 RAID-0 OK - - 64K 298.002 ON OFF u2 SPARE OK - - - 149.042 - OFF u3 RAID-1 OK - - - 149.001 ON OFF
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 WD-WCANM1771318 p1 OK u0 149.05 GB 312581808 WD-WCANM1757592 p2 OK u0 149.05 GB 312581808 WD-WCANM1782201 p3 OK u0 149.05 GB 312581808 WD-WCANM1753998 p4 OK u2 149.05 GB 312581808 WD-WCANM1766952 p5 OK u3 149.05 GB 312581808 WD-WCANM1882472 p6 OK u0 149.05 GB 312581808 WD-WCANM1883862 p7 OK u3 149.05 GB 312581808 WD-WCANM1778008 p8 OK - 149.05 GB 312581808 WD-WCANM1770998 p9 NOT-PRESENT - - - - p10 OK u1 149.05 GB 312581808 WD-WCANM1869003 p11 OK u1 149.05 GB 312581808 WD-WCANM1762464
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 241 22-Jun-2004
Here is the typical output for the 9750, 9690SA and 9650SE controller with Release 9.5.2 or later:
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 SPARE OK - - - 149.042 - OFF u1 JBOD OK - - - 149.051 OFF OFF
VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK - 149.05 GB SATA 3 - WDC WD1600JS-22NCB1 p1 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1 p2 OK u1 149.05 GB SATA 2 - WDC WD1600JS-22NCB1 p3 OK - 34.18 GB SAS 6 - SEAGATE ST936701SS
Note: The 'Cache' column in the unit summary differ between the older (up to 9550SX and 9650SE with Release 9.5.1 or earlier) and newer (9750, 9690SA and 9650SE with Release 9.5.2 or later) controllers. In the unit summary of the "older" controllers, this column shows the state (ON or OFF) of the write cache only. For the "newer" controllers, the 'Cache' column displays the settings of both the read cache and the write cache. For example:
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 596.004 W OFF u1 RAID-0 OK - - 64K 298.002 RiW OFF u2 SPARE OK - - - 149.042 - OFF
In the above example, W denotes that the write cache is enabled, and RiW denotes that Read Cache Intelligent and the Write Cache are both enabled. If OFF is shown then all caches are disabled.
Below is a summary of the possible settings in that column:
W - only the write cache is enabled Rb - only read cache Basic is enabled Ri - only read cache Intelligent is enabled RbW - read cache Basic and write cache are both enabled RiW - read cache Intelligent and write cache are both enabled OFF - all read and write caches are disabled
Note: If read cache Intelligent is enabled, the features in the Basic mode are also enabled.
This command shows the current setting of the given attribute(s). One or many attributes can be requested. An invalid attribute will terminate the loop. Possible attributes are: achip, allunitstatus, autocarve (9550SX and higher), autorebuild (9550SX and higher), bios, carvesize (9550SX and higher), driver, drivestatus, firmware, memory, model, monitor, numdrives, numports, numunits, ctlbus (9550SX and higher), ondegrade (9500S only), pcb, pchip, serial, spinup, stagger, and unitstatus.
This command reports the device driver version associated with controller /cx.
Example:
//localhost> /c0 show driver /c0 Driver Version = 1.02.00.036
This command reports the controller model of controller /cx.
Example:
//localhost> /c0 show model /c0 Model = 7500-12
This command reports the firmware version of controller /cx.
Example:
//localhost> /c0 show firmware /c0 Firmware Version = FE9X 3.03.06.X03
This command reports the BIOS version of controller /cx.
Example:
//localhost> /c0 show bios /c0 BIOS Version = BG9X 2.01.00.026
This command reports the monitor (firmware boot-loader) version of controller /cx.
Example:
//localhost> /c0 show monitor /c0 Monitor Version = BLDR 1.00.00.008
This command reports the serial number of the specified controller /cx.
Example:
//localhost> /c0 show serial /c0 Serial Number = F12705A3240009
This command reports the PCB (Printed Circuit Board) revision of the specified controller /cx.
Example:
//localhost> /c0 show pcb /c0 PCB Version = Rev3
This command reports the PCHIP (PCI Interface Chip) version of the specified controller /cx.
Example:
//localhost> /c0 show pchip
/c0 PCHIP Version = 1.30-33
This command reports the ACHIP (ATA Interface Chip) version of the specified controller /cx.
Example:
//localhost> /c0 show achip
/c0 ACHIP Version = 3.20
For controller models earlier than the 9690SA, this command reports the port capacity (number of physical ports) of the specified controller /cx.
Example:
//localhost> /c0 show numports /c0 Number of Ports = 12
For the 9750 and 9690SA controllers, this command reports the connections and connection capacity of the specified controller /cx. Connections consist of vports and phys.
Example:
//localhost> /c3 show numports /c3 Connections = 4 of 128
This command reports the number of units currently managed by the specified controller /cx. This report does not include off-line units (or removed units).
Example:
//localhost> /c0 show numunits /c0 Number of Units = 1
This command reports the number of drives currently managed by the specified controller /cx. This report does not include (logically) removed/exported drives. Also note that physically removed disk(s) will not be detected unless I/O is performed against the disk. See /cx/px show smart for a workaround.
Example:
//localhost> /c0 show numdrives /c0 Number of Drives = 5
This command presents the number of concurrent disks spin up at the power on.
Example:
//localhost> /c0 show spinup
/c0 Disk Spinup Policy = 1
This command presents the write cache policy for degraded units. If the ondegrade policy is Follow Unit Policy, a unit write cache policy stays the same when the unit becomes degraded. If the ondegrade policy is off, a unit cache policy will force to be off when the unit becomes degraded.
Example:
//localhost> /c0 show ondegrade /c0 Cache on Degraded Policy = Follow Unit Policy
This command presents the time delay between each group of spinups at the power on.
Example:
//localhost> /c0 show stagger /c0 Spinup Stagger Time Policy (sec) = 2
See also:
/cx set stagger=nn /cx set spinup=nn /cx show spinup
This command shows the Auto-Carving policy. If the policy is on, all newly created or migrated units larger than carvesize will be automatically carved into multiples of carvesize volumes and 1 remainder volume. Each volume can be treated as an individual disk with its own file system. The default carvesize is 2 TB.
This feature is useful for operating systems limited to 2 TB filesystems. For 64-bit OS users, there is no need to set the policy to be "on" unless users want to have multiple smaller volumes to the OS. For 32-bit OS users, it is recommended to keep the policy on unless users know their OS supports more than 2 TB disk devices.
When autocarve policy is off, all the new unit creation consists of one single volume.
Example:
//localhost> /c0 show autocarve /c0 Auto-Carving Policy = on
See also:
/cx set autocarve=<on|off> /cx set carvesize=<1024..32768> /cx show carvesize`
This command shows the carvesize that Auto-Carving policy needs. The carve size is between 1024 to 32768 GB (i.e., 1TB-32TB). Default carvesize is 2048 GB (i.e., 2TB). See "/cx show autocarve" command above for details.
Example:
//localhost> /c0 show carvesize /c0 Auto-Carving Size = 2000 GB
This command presents the size of the memory installed on the controller.
Example:
//localhost> /c0 show memory /c0 Available Memory = 112MB
This command presents the controller host bus type, bus speed and bus width.
Example:
//localhost> /c0 show ctlbus
/c0 Controller Bus Type = PCIX /c0 Controller Bus Width = 64 bits /c0 Controller Bus Speed = 133 Mhz
This command shows the Auto-Rebuild policy of the specified controller. If there is a degraded unit and the policy is set to ON, the controller firmware will choose drives in the following order of priority, for a drive candidate to perform the rebuild operation:
1. Smallest usable capacity spare.
2. Smallest usable unconfigured drive.
3. Smallest usable capacity failed drive.
If the policy is set to OFF, spare drives are the only candidates for an automatic rebuild operation.
Example:
//localhost> /c0 show autorebuild /c0 Auto-Rebuild Policy = on
See also:
/cx set autorebuild=<on|off>
This command, without specifying the type option, shows the configuration and setting of the Drive Performance Monitor. Display will also show the default set of drive statistics of type Instantaneous.
The optional 'type' in the command specifies which statistics would be displayed. The options are either: inst for Instantaneous, ra for Running Average, and ext for Extended Drive Statistics. More detailed information regarding these statistics and the Drive Performance Monitor is available in the Features section under 'Drive Performance Monitor'.
For example:
//localhost> /c0 show dpmstat Drive Performance Monitor Configuration for /c0 ... Performance Monitor: ON Version: 1 Max commands for averaging: 100 Max latency commands to save: 10 Requested data: Instantaneous Drive Statistics
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
------------------------------------------------------------------------
p0 NOT-PRESENT - - - - -
p1 NOT-PRESENT - - - - -
p2 OK - - - - -
p3 OK u0 10 93 2.907 85
p4 OK u1 10 84 2.640 95
p5 OK - - - - -
p6 NOT-PRESENT - - - - -
p7 NOT-PRESENT - - - - -
Please note that as a controller level command, the output provides summary information of the set of drives in the controller, as opposed to the corresponding port-level command with the same options, that displays correspondingly the same statistics but for the specified port only.
Also, for examples of other statistic data types, please see the 'Features' section.
This command presents a list of units, their types, capacity and status currently managed by the specified controller /cx.
Example:
//localhost> /c2 show unitstatus
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 596.004 ON OFF u1 RAID-0 OK - - 64K 298.002 ON OFF u2 SPARE OK - - - 149.042 - OFF u3 RAID-1 OK - - - 149.001 ON OFF
This command presents a count of Total and Not Optimal units managed by the specified controller /cx. See Shell Object Messages for more on Not Optimal definition.
Example:
//localhost> /c0 show allunitstatus
/c0 Total Optimal Units = 2 /c0 Not Optimal Units = 0
This command presents a list of drives, port assignment, vendor signature, size, status, and unit membership/affiliation.
Example:
//localhost> /c0 show drivestatus
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 3JS0TF14 p1 OK u0 149.05 GB 312581808 3JS0TETZ p2 OK u1 149.05 GB 312581808 3JS0VG85 p3 OK u1 149.05 GB 312581808 3JS0VGCY p4 OK u1 149.05 GB 312581808 3JS0VGGQ p5 OK u2 149.05 GB 312581808 3JS0VH1P p6 OK - 149.05 GB 312581808 3JS0TF0P p7 OK - 149.05 GB 312581808 3JS0VF43 p8 OK - 149.05 GB 312581808 3JS0VG8D p9 NOT-PRESENT - - - - p10 NOT-PRESENT - - - - p11 NOT-PRESENT - - - -
This command shows the current setting of all attributes.
This command allows you to add a new unit or create a unit on the specified controller /cx, of type RaidType, optional stripe size of Stripe, using one or many disks specified by disk=p:-p. By default the host operating system will be informed of the new block device and write cache is enabled. In case of RAID-50, you can also specify the layout of the unit by specifying the number of disks per disk group with group=3|4|5|6|7|8 attribute.
Upon the success of the new unit creation, a unique serial number is also assigned to the new unit. Please refer to commands /cx/ux show serial for checking.
Please Note: 1) The default of the unit creation sets write cache to "on" for performance reasons. However, if there is no BBU available for the controller, a warning is sent to standard error. 2) The default drive queuing policy is enabled, unless it is specifically set to disable queuing by specifing noqpolicy. 3) The noqpolicy attribute is not applicable to the "spare" unit. Specifying the noqpolicy attribute returns an error.
Since this command is by far the richest command, it deserves more details.
/cx is the controller name as in /c0, /c1, etc.
type=RaidType consists of logical unit type as in raid0, raid1, raid5, raid10, raid50, single, spare, and raid6 (9650SE and higher only).
For example:
type=raid50
The following table illustrates supported types and controller models.
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single | Raid6 | ------+-------+-------+-------+--------+------+-------+--------+--------+-------+ 7K/8K | Y | Y | Y | Y | Y | Y | N | N | N | ------+-------+-------+-------+--------+------+-------+--------+--------+-------+ 9K | Y | Y | Y | Y | N | Y | Y | Y | N | ------+-------+-------+-------+--------+------+-------+--------+--------+-------+ 9650SE| | | | | | | | | | and | Y | Y | Y | Y | N | Y | Y | Y | Y | higher| | | | | | | | | | ------+-------+-------+-------+--------+------+-------+--------+--------+-------+
disk=p:-p consists of a list of ports (disks) to be used in the construction of the specified unit type. One or more ports can be specified. Multiple ports can be specified using ":" or "-" as port index separators. A dash indicates a range and can be mixed with ":". For example disk=0:1:2-5:9:12 indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12.
stripe=size consists of the stripe size to be used. The following table illustrates the supported and applicable stripes on unit types and controller models. Stripe size of units are in KB (kilobytes).
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | Raid50 | JBOD | Spare | Single |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
7K/8K | 64 | N/A | 64 | N/A | 64 | N/A | N/A | N/A | N/A |
| 128 | | | | 128 | | | | |
| 256 | | | | 256 | | | | |
| 512 | | | | 512 | | | | |
| 1024 | | | | 1024 | | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
9K | 16 | N/A | 16 | N/A | 16 | 16 | N/A | N/A | N/A |
| 64 | | 64 | | 64 | 64 | | | |
| 256 | | 256 | | 256 | 256 | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
9650SE| 16 | N/A | 16 | | 16 | 16 | N/A | N/A | N/A |
and | 64 | | 64 | 64 | 64 | 65 | | | |
higher| 256 | | 256 | 256 | 256 | 256 | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
group=3|4|5|6|7|8|9|10|11|12|13|14|15|16 consists of the number of disks per group for a Raid 50 type. Note: This attribute can only be used when type=raid50. Also, group=13-16 is applicable to the 9690SA and 9750 controllers only.
Recall that a RAID-50 is a multi-tier array. At the most bottom layer, N number of disks per group are used to form the RAID-5 layer. These RAID-5 arrays are then integrated into a RAID-0. This attribute allows you to specify the number of disks in the RAID-5 level. Valid values are 3, 4, 5, 6, 7 and 8.
Note that a sufficient number of disks are required for a given pattern or disk group. For example, given 6 disks, specifying 3 will create two RAID-5. However given 12 disks, specifying 3 will create four RAID-5 under the RAID-0 level. Given 6 disks and grouping of 6 is not allowed, as you'll basically be creating a RAID-5.
The default group varies based on number of disks. For 6 & 9 disks, default is group=3. For 8 disks, default is group=4. For 10 or 15 disks, default is group=5. For 12 or 16 disks, default is group=4. For 14 disks, default is group=7. Case of 12 disks could be grouped with group=3, group=4, or group=6. Group=4 was set by default as it provides best net capacity and performance. Case of 15 disks could be grouped with group=3 or group=5. And case of 16 disks could be grouped with group=4 and group=8.
Note that the supported group number indicated depends on the number of ports on the controller. group=16 is the maximum and it is available on the 9690SA and 9750 controllers only.
noscan attribute instructs CLI not to notify OS of creation of the new unit. By default CLI will inform the OS. One application of this feature is to avoid the OS from creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and creating a moving target.
nocache or nowrcache attribute instructs CLI to disable the write cache on the newly created unit. Enabling the write cache increases performance at the cost of high-availability. No caching is recommended when no BBU or UPS is installed. The system default for the write cache is enable. If a BBU or UPS is not installed, to avoid possibility of data loss in the event of sudden power loss, it is recommended that nocache or nowrcache be specified.
nordcache attribute instructs CLI to disable the read cache on the newly created unit. Enabling the read cache increases performance. The rdcachebasic attribute instructs CLI to set the read cache mode on the newly created unit to Basic. Please note that it is not necessary to include any read cache attribute if you wish to select the Intelligent mode of Read Cache, since the system default is Read Cache Intelligent. See "/cx/ux set rdcache" for more information.
autoverify|noautoverify attribute enables or disables, respectively, the autoverify attribute on the unit that is to be created. For more details on this feature, refer to the /cx/ux set autoverify command section of this document. This feature is not supported on controller models 7000/8000. For the 9650SE, 9690SA, and 9750 controllers that support Basic Verify, autoverify will be set to ON by default for the new unit to be created. For other 9000 series controllers that do not support Basic Verify, autoverify is set to OFF by default for the new unit. The following table should help clarify regarding the defaults:
---------------------+--------------------+----------------------
"ADD" COMMAND | 9550SX AND HIGHER | 9650SE AND HIGHER
ATTRIBUTE | (No BV support) | (has BV support)
---------------------+--------------------+----------------------
None specified | |
(i.e., use default) | autoverify = OFF | autoverify = ON
---------------------+--------------------+----------------------
autoverify | Enables AutoVerify |
| autoverify = ON | No effect*
---------------------+--------------------+----------------------
noautoverify | | Enables AutoVerify
| No effect* | autoverify = ON
---------------------+--------------------+----------------------
*No effect means that, issuing the add command attribute of that row would
be the same as not issuing any attribute and using the default.
Note: while there is no reason to issue both autoverify and noautoverify together at unit creation, CLI allows you to do so. Keep in mind however, that in this case, only the last value specified would be used. That is, for example, if you specified the command '/c0 add type=raid5 disk=0-2 autoverify noautoverify', then you are essentially specifying that 'autoverify=OFF' for /c0.
noqpolicy attribute instructs CLI to disable the qpolicy (drive queuing) on the newly created unit. The default qpolicy is on (i.e., noqpolicy is not specified). For the spare unit, drive queueing is not meaningful and the qpolicy cannot be set. During unit creation, specifying noqpolicy for spare returns an error.
ignoreECC attribute enables the ignoreECC/OverwriteECC attribute on the unit that is to be created. For more details on this feature, refer to /cx/ux set commands section of this document. The following table illustrates the supported Model / Unit Type. This table only applies to setting this feature at unit creation time. Generally, ignoreECC applies to redundant units.
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | JBOD | Spare | Raid50 | Single | --------+-------+-------+-------+-------+--------+------+-------+--------+--------+ 7K/8K | N | N | N | N/A | N | N | N | N | N | --------+-------+-------+-------+-------+--------+------+-------+--------+--------+ 9K | N | Y | Y | N/A | Y | N | N | Y | N | --------+-------+-------+-------+-------+--------+------+-------+--------+--------+ 9650SE | N | Y | Y | Y | Y | N | N | Y | N | and | | | | | | | | | | higher | | | | | | | | | | --------+-------+-------+-------+-------+--------+------+-------+--------+--------+
name=string attribute allows user to name the new unit. The maximum characters allowed for the string are 21. No space is allowed within the string. If user likes to use some special characters which the OS command shell reserves such as '<', '>', '!', and '&', etc in the name string, the user has to use quote "" around the name string in order to bypass the command shell. User can change the name of the unit any time after the unit creation. This is a feature for 9000 or above series of controllers. Please refer to commands /cx/ux set name=sting for changing the name and /cx/ux show name for checking.
storsave=protect|balance|perform attribute allows user to set the storsave policy of the new unit. This feature is for controller models 9550SX and higher only. Please refer to the command /cx/ux set storsave=protect|balance|perform for detail.
Either the v0=n or vol=a:b:c:d attribute may be used to set the size of the first volume or (up to) the first 4 volumes of the new unit, respectively. The first volume may, but not necessarily, be the boot LUN. The value(s) should be positive integer(s) in units of gigabytes (GB). Zero (0) is an invalid LUN size input value. The upper user input limit is 32TB. Note that there are two ways to set the first volume, as either v0=n or vol=n would have the same effect.
Note: If the total size of the specified volumes (up to 4) exceeds the size of the array, the volume(s) of size(s) that exceeded the array boundary will not be carved.
Example (RAID-5 being created with the first volume size set to 10 GB):
//localhost> /c0 add type=raid5 disk=2-5 v0=10
Creating new unit on Controller /c0 ... Done. The new unit is /c0/u0. Setting write cache=ON for the new unit ... Done. Setting default Command Queuing Policy for unit /c0/u0 to [on] ... Done.
After the unit creation, a subsequent "show" command for the unit would show the volume sizes:
//localhost> /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-5 OK - - - 64K 1117.56 u0-0 DISK OK - - p2 - 372.519 u0-1 DISK OK - - p3 - 372.519 u0-2 DISK OK - - p4 - 372.519 u0-3 DISK OK - - p5 - 372.519 u0/v0 Volume - - - - - 10 u0/v1 Volume - - - - - 1107.56
Example (RAID-0 being created with the volume sizes set to 45, 20, 50, and 12 GB):
//localhost> /c3 add type=raid0 disk=0-1 vol=45:20:50:12
Creating new unit on controller /c3 ... Done. The new unit is /c3/u0. Setting write cache=ON for the new unit ... Done. Setting default Command Queuing Policy for unit /c3/u0 to [on] ... Done.
After the unit creation, a subsequent "show" command for the unit would show the volume sizes:
//localhost> /c3/u0 show
Unit UnitType Status %RCmpl %V/I/M VPort Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-0 OK - - - 64K 298.002 u0-0 DISK OK - - p0 - 149.001 u0-1 DISK OK - - p1 - 149.001 u0/v0 Volume - - - - - 45 u0/v1 Volume - - - - - 20 u0/v2 Volume - - - - - 50 u0/v3 Volume - - - - - 12 u0/v4 Volume - - - - - 171.002
The attribute rapidrecovery specifies the Rapid RAID Recovery setting for the unit to be created. Rapid RAID Recovery can speed up the rebuild process, and it can speed up the initialize and verify tasks for redundant arrays in the RAID system upon the event of an unclean system shutdown. This feature allows for expedited boot-up time in the event of an unclean shutdown. Setting this option to all applies the policy to the rebuild, initialize and verify tasks at reboot. Setting it to rebuild applies the policy to the rebuild tasks only. If the policy is set to disable, then none of the tasks would be sped up.
Note: Once this attribute is set, the policy setting is persistent in the system until it is disabled. Also, once disabled, that setting could not be changed for that unit at a later time.
Note: This attribute is for controller models 9750, 9690SA and 9650SE (with supporting firmware), and is for redundant arrays only. In addition, Rapid RAID Recovery is not supported over migration.
Note: The default setting of Rapid RAID Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled.
This command instructs the controller to rescan all ports and reconstitute all units. The controller will update its list of ports (attached disks), and visits every DCB (Disk Configuration Block) in order to re-assemble its view and awareness of logical units. Any newly found unit(s) or drive(s) will be listed. noscan is used to not inform the OS of the unit discovery. Default is to inform the OS.
Example:
//localhost> /c1 rescan
Rescanning controller /c1 for units and drives ...Done. Found following unit(s): [/c1/u3]. Found following drive(s): [/c1/p7, /c1/p8].
Note: Does not import non-JBOD on 7000/8000 models.
This command instructs the controller to commit its dirty DCBs to persistent storage (ie disks). While controller is processing I/O requests against underlying disks, an in-transaction bit is set. If a failure (such as power failure) is experienced, subsequent read from the disks, will inform the controller that an un-clean shutdown took place. This command allows the end user to complete all pending I/Os on disks and clear the in-transaction bit.
Typical application of this feature is when an application is using a given unit in raw mode (such as databases) and user would like to shutdown the host (Including UPS post failure automations). This command can then expedite the process by instructing the controller to finish pending requests, clear DCB's in-transaction flag as we are going down.
Note that block devices (cooked devices) do not require this and clients of block devices (such as file systems) will send its own shutdown request to the devices.
This command only applies to Windows operating system.
This command allows you to flush the write cache on all units associated with the /cx controller
This command allows the download of the specified firmware image to the corresponding controller. This command is for 9000 series controllers only.
fw=filename_with_path attribute allows the user to specify the firmware image file name along with its path. Please note that filename_with_path could not have spaces in the directory names of its path (as Windows would allow).
The new image specified by filename_with_path will be checked for compatibility with the current controller, current driver and current application versions. Subsequently a recommendation is given to the user followed by a prompt to continue. Once the user decides to proceed, the image will be downloaded to the controller. However, a reboot is required for the new image to take effect.
Example:
//localhost> /c2 update fw=/tmp/prom0006.img
Warning: Updating the firmware can render the device driver and/or management tools incompatible. Before you update the firmware, it is recommended that you:
1) Back up your data.
2) Make sure you have a copy of the current firmware image so that you can roll back, if necessary.
3) Close all applications.
Examining compatibility data from firmware image and /c2 ... Done.
New-Firmware Current-Firmware Current-Driver Current-API ---------------------------------------------------------------------- FE9X 3.05.00.005 FE9X 3.05.00.005 2.26.04.007 2.01.00.008
Current firmware version is the same as the new firmware. Recommendation: No need to update.
Given the above recommendation... Do you want to continue ? Y|N [N]: y Downloading the firmware from file /tmp/prom0006.img ... Done. The new image will take effect after reboot.
The force attribute is optional. With it the warning message is suppressed, as well as the prompt to proceed. Compatibility checks are not bypassed. If the image to be downloaded is not compatible, an error message will be shown. If the image to be downloaded is compatible, a message will indicate the downloading of the image.
Asynchronous events or AENs (Asynchronous Event Notifications) of the controller, also known as 'controller alarms', are originated by firmware and captured by their respective device drivers. These events are kept in a finite queue inside the kernel, awaiting extraction by user space programs such as CLI and/or 3DM2. These events reflect messages of varying severity levels. The levels range in order of severity: INFO, WARNING, and ERROR, respectively.
Controller Events or Alarms generated on the 7000/8000 series controllers do not have dates, as such a dash ('-') indicating 'read not-applicable' is displayed in the "Date" column. Also, with the 7000/8000 series controllers, the event message contains the severity as well, hence the "Severity" column shows a '-' also.
This command displays all available events on a given controller. The default listing order is 'ascending'; that is, the later the alarm or event message the further down in the list or table it appears in. Likewise, the older the event message the earlier it is in the table. The order of the messages could be reversed with the attribute reverse. With this the most recent AEN message would appear at the top of the table.
Typical output looks like:
//localhost> /c1 show events
Ctl Date Severity AEN Message ------------------------------------------------------------------------------ c0 [Fri Mar 21 2008 14:19:00] WARNING Drive removed: port=1 c0 [Fri Mar 21 2008 14:19:00] ERROR Degraded unit: unit=1, port=1 c0 [Fri Mar 21 2008 14:19:25] INFO Drive inserted: port=1 c0 [Fri Mar 21 2008 14:19:25] INFO Unit operational: unit=1 c0 [Fri Mar 21 2008 14:28:18] INFO Migration started: unit=0 c0 [Sat Mar 22 2008 05:16:49] INFO Migration completed: unit=0 c0 [Tue Apr 01 2008 12:34:02] WARNING Drive removed: port=1 c0 [Tue Apr 01 2008 12:34:22] ERROR Unit inoperable: unit=1 c0 [Tue Apr 01 2008 12:34:23] INFO Drive inserted: port=1 c0 [Tue Apr 01 2008 12:34:23] INFO Unit operational: unit=1
This command extracts controller diagnostics suitable for technical support usage.
Note that some characters might not be printable or rendered correctly (human
readable). It is recommended to save this output to a file, where it can be
communicated to tech support or further studied with Linux utilities like od(1).
Example:
$ tw_cli /c0 show diag > diag.txt
This command is for the 9650SE with Release 9.5.2 or later, and the 9690SA or newer controllers only. It reports a list of phys with related information for the specified controller. The 'Device Type' column indicates whether the connected device is an enclosure, or a drive of type SATA or SAS. The 'Device' column is the device ID or handle. There are three 'Link Speed' columns: 'Supported' denotes the link speed capability of the phy/device, 'Enable' denotes the current link speed setting, and 'Control' denotes the link control setting.
Example of 9690SA-8E connected to drives in an enclosure:
//localhost> /c3 show phy
Device --- Link Speed (Gbps) ---
Phy SAS Address Type Device Supported Enabled Control
-----------------------------------------------------------------------------
phy0 500050e000030232 ENCL N/A 1.5-3.0 3.0 Auto
phy1 500050e000030232 ENCL N/A 1.5-3.0 3.0 Auto
phy2 500050e000030232 ENCL N/A 1.5-3.0 3.0 Auto
phy3 500050e000030232 ENCL N/A 1.5-3.0 3.0 Auto
phy4 500050e000030236 ENCL N/A 1.5-3.0 3.0 Auto
phy5 500050e000030236 ECNL N/A 1.5-3.0 3.0 Auto
phy6 500050e000030236 ENCL N/A 1.5-3.0 3.0 Auto
phy7 500050e000030236 ECNL N/A 1.5-3.0 3.0 Auto
In the above example, for phy1, the link speeds supported are 1.5 and 3.0 Gpbs. The current link speed for phy1 is 3.0 Gpbs, and the link control setting is 'Auto'. The link control setting could be either 1.5, 3.0, or Auto. 'Auto' denotes Automatic Negotiation, where the best negotiated speed possible for that link will be used.
Example of 9690SA-8I with directly attached drives:
//localhost> /c3 show phy
Device --- Link Speed (Gbps) ---
Phy SAS Address Type Device Supported Enabled Control
-----------------------------------------------------------------------------
phy0 500050e000000002 SATA /c3/p0 1.5-3.0 3.0 Auto
phy1 500050e000000002 SATA /c3/p1 1.5-3.0 3.0 Auto
phy2 500050e000000002 SATA /c3/p2 1.5-3.0 3.0 Auto
phy3 500050e000000002 SATA /c3/p3 1.5-3.0 3.0 Auto
phy4 - - - - - -
phy5 - - - - - -
phy6 500050e000000006 SAS /c3/p6 1.5-3.0 3.0 Auto
phy7 - - - - - -
Note: There is no "/cx set phy" command. Moreover, the only changeable setting for phy is link speed. To change the link speed, see the /cx/phyx set link command. To see information for an individual phy only, use /cx/phyx show. These commands are in the "Phy Object Messages" section.
Model 9000 series controllers support background tasks such as rebuild, verify, or self test activities. For each activity, up to 7 tasks can be registered, known as slots 1 through 7. Each task activity can be managed by a set of commands including add, del, show and set. Background tasks have a slot id, start day, hour, duration, and status attributes.
Rebuild activity attempts to (re)synchronize all members of redundant units such as RAID-1, RAID-10, RAID-5 and RAID-50. Rebuilds can be started manually or automatically if a spare has been defined. Scheduled rebuilds will take place during the scheduled window, if enabled.
This command displays the current rebuild background task schedule as illustrated below.
$ tw_cli /c1 show rebuild
Rebuild Schedule for Controller /c1 ======================================================== Slot Day Hour Duration Status -------------------------------------------------------- 1 Mon 2:00pm 10 hr(s) disabled 2 Thu 7:00pm 18 hr(s) disabled 3 - - - - 4 - - - - 5 - - - - 6 Mon 1:00am 4 hr(s) disabled 7 Sun 12:00am 1 hr(s) disabled
The status of disabled denotes that the controller will not use the scheduled time slots.
This command shows the current rebuild mode setting of the specified controller. The rebuild mode has two settings: "Adaptive" and "Low latency".
The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting "throttles" the background task and allow host Reads to complete, thus improves performance in the situation when a rebuild background task is active with the task rate has been set to high (that is, low I/O rate).
This command is associated with the rebuild task rate, please also see /cx show rebuildrate.
This command is supported on the 9650SE controller with Release 9.5.2 or later and for the 9690SA and higher model controllers.
Example:
//localhost> /c1 show rebuildmode /c1 Rebuild background task mode = Low Latency
See also:
/cx set rebuildmode=<adaptive|lowlatency> /cx set rebuildrate=<1..5> /cx show rebuildrate
The execution priority relative to I/O operations for the rebuild background task is the rebuild task rate. This command shows the current rebuild task rate of the specified controller.
This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows:
5 = fastest rebuild; slowest I/O 4 = faster rebuild; slower I/O 3 = balanced between rebuild and I/O 2 = faster I/O; slower rebuild 1 = fastest I/O; slowest rebuild
This command applies to the 7000, 8000, and 9000 models controllers.
For example:
//localhost> /c1 show rebuildrate /c1 Rebuild background task rate = 4 (faster rebuild; slower I/O)
See also:
/cx set rebuildrate=<1..5> /cx set rebuildmode=<adaptive|lowlatency> /cx show rebuildmode
Verify is one of the supported background tasks, and this command displays the current verify schedule.
For the 9650SE and newer RAID controllers, the Verify Task Schedule can be either basic or advanced (For details about the two types and the associated commands, please see the 'Features' section.) The basic Verify Task Schedule sets a weekly day and time for verification to occur, and is designed to be used with unit auto-verify. The advanced Verify Task Schedule provides more control, and is equivalent to the Verify Task Schedule available for 9550SX and earlier RAID controllers.
For the advanced Verify Task Schedule, up to 7 time periods can be registered, known as timeslots (or simply slots) 1 through 7. This task schedule can be managed by a set of commands including add, del, show and set. The task schedule has a slot id, start-day-time, duration, and status attributes. Rebuild follow similar background task schedules.
For details about setting up a schedule for verify tasks, see /cx set verify.
Verify activity attempts to verify all units based on their unit type. Verifying RAID-1 involves checking that both drives contain the exact data. On RAID-5 and RAID-6, the parity information is used to verify data integrity. RAID-10 and 50 are composite types and follow their respective array types. On the 9000 series, non-redundant units such as RAID-0, JBOD, single, and spare, are also verified (by reading and reporting un-readable sectors).
Example 1: For the 9550SX and older controllers, and when verify=advanced for the 9650SE and newer controllers, the show verify command displays the current verify background task schedule as illustrated below.
$ tw_cli /c1 show verify
Verify Schedule for Controller /c1 ======================================================== Slot Day Hour Duration Status -------------------------------------------------------- 1 Mon 2:00am 4 hr(s) disabled 2 - - - - 3 Tue 12:00am 24 hr(s) disabled 4 Wed 12:00am 24 hr(s) disabled 5 Thu 12:00am 24 hr(s) disabled 6 Fri 12:00am 24 hr(s) disabled 7 Sat 12:00am 24 hr(s) disabled
The status of disabled denotes that the controller will not use the scheduled time slots.
Example 2: For the 9650SE and newer controllers, if the basic Verify Task Schedule is selected, the show verify command displays the following:
//localhost> /c1 show verify /c1 basic verify weekly preferred start: Friday 12:00am
This command shows the current verify mode setting of the specified controller. The verify mode has two settings: "Adaptive" and "Low latency".
The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting "throttles" the background task and allow host Reads to complete, thus improves performance in the situation when a verify background task is active with the task rate has been set to high (that is, low I/O rate).
This command is associated with the verify task rate, please also see /cx show verifyrate.
This command is supported on the 9650SE controller with Release 9.5.2 or higher, and for the 9690SA and higher model controllers.
Example:
//localhost> /c1 show verifymode /c1 Verify background task mode = Low Latency
See also:
/cx set verifymode=<adaptive|lowlatency> /cx set verifyrate=<1..5> /cx show verifyrate
The execution priority relative to I/O operations for the verify background task is the verify task rate. This command shows the current verify task rate of the specified controller.
This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows:
5 = fastest verify; slowest I/O 4 = faster verify; slower I/O 3 = balanced between verify and I/O 2 = faster I/O; slower verify 1 = fastest I/O; slowest verify
This command applies to the 7000, 8000, and 9000 models controllers.
For example:
//localhost> /c1 show verifyrate /c1 Verify background task rate = 4 (faster rebuild; slower I/O)
See also:
/cx set verifyrate=<1..5> /cx set verifymode=<adaptive|lowlatency> /cx show verifymode
Model 9000 series controllers support background tasks such as rebuild, verify, and self test activities. For each activity, up to 7 tasks can be registered, known as slots 1 through 7. Each activity can be managed by a set of commands including add, del, show and set a task. Background tasks have attributes of slot id, start-day-time, duration, and status.
The selftest that would be performed is called SMART (Self Monitoring Analysis and Reporting). The SMART selftest instructs the controller to check certain SMART supported thresholds by the disk vendor. An AEN is logged to the alarms table if a drive reports a SMART failure. The failing drive should be replaced if this error occurs.
This command displays the current selftest background task schedule as illustrated below.
$ tw_cli /c1 show selftest
Selftest Schedule for Controller /c1 =========================================== Slot Day Hour SMART ------------------------------------------- 1 Sun 12:00am enabled 2 Mon 12:00am enabled 3 Tue 12:00am enabled 4 Wed 12:00am enabled 5 Thu 12:00am enabled 6 Fri 12:00am enabled 7 Sat 12:00am enabled
This command registers a new background rebuild task to the schedule, for execution on the day of ddd (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at the hour of hh (range 0 .. 23), for a duration of duration (range 1 .. 24) hours. This command will fail if no (empty) slot is available. In that case, you would need to delete an existing slot before adding.
For "rebuild" background task description, see command /cx show rebuild.
For example:
//localhost> /c3 add rebuild=sun:16:3 Adding scheduled rebuild to slot 7 for [Sun, 4:00PM, 3hr(s)] ... Done.
This command registers a new task slot to the Verify Task Schedule on the day of ddd (where ddd is Sun, Mon, Tue, Wed, Fri, or Sat), at the hour of hh (range 0..23), for a duration of duration (range 1..24) hours. A maximum of seven verify task slots can be included in the schedule. This command will fail if no (empty) task slot is available. In that case, you would need to delete an existing slot before adding.
Note: This Verify Task Schedule is used when '/cx set verify=advanced' for the 9650SE with Release 9.5.2 or later, and 9690SA and higher model controllers, and for the 9650SE with Release 9.5.1 or earlier and 9550SX or older controllers when '/cx set verify=enabled'.
Note: If you have a 9650SE with Release 9.5.2 or later, or a 9690SA or newer controller, you may use the simpler basic verify schedule with the command /cx set verify=basic. Simply specify a weekly day and time and make sure that the auto-verify policy is set to ON for your RAID units. For more information please see '/cx set verify=basic' or the section on Basic Verify in the Features section of this document.
Example:
//localhost> /c3 add verify=sun:23:2 Adding scheduled verify to slot 3 for [Sun, 11:00PM, 2hr(s)] ... Done.
In the above example, a verify task slot is added to the schedule to be executed in the 2-hour duration time window on Sundays at 11:00 PM.
Note: Use the /cx/ux set autoverify=on command to turn on autoverify for each unit you wish to follow the schedule.
This command registers a new background selftest task to the schedule, for executed on day of ddd (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at hour of hh (range 0 .. 23). Notice that selftest runs to completion and as such no duration value is required. This command will fail if no (empty) slot is available. In that case, you would need to delete an existing slot before adding.
For "selftest" background task description, see command /cx show selftest.
Example:
//localhost> /c1 add selftest=Sun:16 Adding scheduled verify to slot 7 for [Sun, 4:00PM] ... Done.
This command will remove (or unregister) the rebuild background task in slot slot_id.
For "rebuild" background task description, see command /cx show rebuild.
Example:
$ tw_cli /c1 del rebuild=2 Removing scheduled rebuild slot [2] ... Done.
WARNING: If all timeslots are removed, be sure to also disable the schedule. Otherwise, no firmware initiated or manually started rebuild tasks would run.
This command will remove (or unregister) the verify background task in slot slot_id.
For "verify" background task description, see command /cx show verify.
Example:
$ tw_cli /c1 del verify=3 Removing scheduled verify slot [3] ... Done.
WARNING: If all timeslots are removed, be sure to also disable the schedule. Otherwise, no firmware initiated or manually started verify tasks would run.
This command will remove (or unregister) the selftest background task in slot slot_id.
For "selftest" background task description, see command /cx show selftest.
Example:
$ tw_cli /c1 del selftest=3 Removing scheduled selftest slot [3] ... Done.
This command will enable or disable all of the scheduled rebuild background tasks on controller /cx. When enabled, only registered or scheduled tasks will execute. Any previous on-demand (manually started) background tasks will be ignored.
This command also allows you to set the rebuild task rate. Setting this value to 5 implies that the rebuild will consume 100% of the controller's resource (cpu time, I/O bandwidth) to complete its task. Conversely setting this value to 1 implies that I/O operations has higher priority and the rebuild will consume minimal resource. In other words:
5 = fastest rebuild; slowest I/O 4 = faster rebuild; slower I/O 3 = balanced between rebuild and I/O 2 = faster I/O; slower rebuild 1 = fastest I/O; slowest rebuild
This command applies to 7000, 8000, and 9000 models controllers. For 7/8000 series, the rebuild rate also applies to verify and mediascan tasks.
For "rebuild" background task description, see command /cx show rebuild.
When a rebuild background task is active, if the task rate is set to high (i.e., low I/O rate), the system latency increases and performance is negatively affected. This command allows you to offset this condition by setting the rebuild mode to low latency. This setting will "throttle" the background task and allow host Reads to complete, thus improving performance.
The rebuild mode has two settings: "Adaptive" and "Low latency". The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting has been described above.
This command is associated with the rebuild task rate, please also see /cx set rebuildrate.
This command is supported on the 9650SE controller with Release 9.5.2 or later, and for the 9690SA and higher model controllers.
Note: Setting rebuildmode to 'low latency' and rebuildrate to '1' is not recommended when I/O is active, because in that case, the rebuild as a background task may never complete. Thus, this setting should be used with care.
Example:
//localhost> /c1 set rebuildmode=lowlatency Setting Rebuild background task mode on /c1 to [lowlatency] ... Done.
See also:
/cx show rebuildmode /cx set rebuildrate=<1..5> /cx show rebuildrate
The execution priority relative to I/O operations for the rebuild background task is the rebuild task rate. The rebuild task rate set to "fastest" will consume all of the controller's resources and will correspondingly deter I/O operations. Accordingly, the converse is also true.
This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows:
5 = fastest rebuild; slowest I/O 4 = faster rebuild; slower I/O 3 = balanced between rebuild and I/O 2 = faster I/O; slower rebuild 1 = fastest I/O; slowest rebuild
This command applies to the 7000, 8000, and 9000 models controllers.
Example:
//localhost> /c1 set rebuildrate=2 Setting Rebuild background task rate on /c1 to [2] (faster I/O) ... Done.
See also:
/cx show rebuildrate /cx set rebuildmode=<adaptive|lowlatency> /cx show rebuildmode
This command will enable or disable all of the scheduled verify background tasks on controller /cx. When enabled, only registered or scheduled tasks will execute. Any previous on-demand (manually started) background tasks will be ignored.
This command allows you to set the verify task rate. Setting this value to 5 implies that the verify will consume 100% of the controller's resource (cpu time, I/O bandwidth) to complete its task. Conversely setting this value to 1 implies that I/O operations has higher priority and the verify will consume minimal resource. In other words:
5 = fastest verify; slowest I/O 4 = faster verify; slower I/O 3 = balanced between verify and I/O 2 = faster I/O; slower verify 1 = fastest I/O; slowest verify
Note that this feature only applies to 9000 and higher controller models.
For "verify" background task description, see command /cx show verify.
Note: Enabling verify with this command is equivalent to using the '/cx set verify=advanced' command for 9650SE and 9690SA controllers. For 9650SE and higher model controllers, disabling verify with this command is equivalent to using the '/cx set verify=basic' command without specifying a preferred start day and time (the default of Friday midnight/Saturday morning is used.)
Note: If you want verify to occur automatically, when enabling the verify schedule you must also remember to enable the autoverify setting for the units to be verified. For more information, see the command '/cx/ux set autoverify'.
This command only applies to controller models 9750, 9690SA and 9650SE with Release 9.5.2 or later.
This command is effectively the same as the 'set verify' command. Setting verify to advanced enables the Verify Tasks Schedule, which can include a series of up to 7 days and times. Setting verify to basic creates a weekly schedule with one specific day and time, and disables the series of scheduling slots associated with the advanced verify task schedule.
This command only applies to 9650SE and higher model controllers.
Using the verify=basic option allows you to set a basic verify schedule that starts each week at the same date and time. With verify=basic, you can specify your preferred day and time, or use the default weekly schedule of Friday midnight/Saturday morning.
When you set verify=basic, the table of scheduled time slots associated with the advanced Verify Task Schedule is ignored.
Verify=basic is intended to be used with the auto-verify policy for RAID units, to insure that a unit verify process occurs on a regular basis. Also, for this reason, in systems that support Basic Verify, auto-verify is set to ON by default.
Note: When verify=basic, if you start a manual verify, it will start immediately. When verify=advanced, if you start a manual verify, it will follow the advanced Verify Task Schedule. For more information, see /cx/ux start verify.
For example:
//localhost> /c3 set verify=basic pref=Fri:23 Setting /c3 basic verify preferred start time to [Fri, 11:00PM] ... Done.
When a verify background task is active, if the task rate is set to high (i.e., low I/O rate), the system latency increases and performance is negatively affected. This command allows you to offset this condition by setting the rebuild mode to low latency. This setting will "throttle" the background task and allow host Reads to complete, thus improving performance.
The verify mode has two settings: "Adaptive" and "Low latency". The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting has been described above.
This command is associated with the verify task rate, please also see /cx set verifyrate.
This command is supported on the 9650SE controller with Release 9.5.2 or later and for the 9690SA and higher model controllers.
Note: Setting verifymode to 'low latency' and verifyrate to '1' is not recommended when I/O is active, because in that case, the verify as a background task may never complete. Thus, this setting should be used with care.
Example:
//localhost> /c1 set verifymode=lowlatency Setting Verify background task mode on /c1 to [lowlatency] ... Done.
See also:
/cx show verifymode /cx set verifyrate=<1..5> /cx show verifyrate
The execution priority relative to I/O operations for the verify background task is the verify task rate. The verify task rate set to "fastest" will consume all of the controller's resources to complete the task and will correspondingly deter I/O operations. Accordingly, the converse is also true.
This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows:
5 = fastest verify; slowest I/O 4 = faster verify; slower I/O 3 = balanced between verify and I/O 2 = faster I/O; slower verify 1 = fastest I/O; slowest verify
This command applies to the 7000, 8000, and 9000 models controllers.
Example:
//localhost> /c1 set verifyrate=2 Setting Verify background task rate on /c1 to [2] (faster I/O) ... Done.
See also:
/cx show verifyrate /cx set verifymode=<adaptive|lowlatency> /cx show verifymode
This command will enable or disable the SMART selftest task on on the specified controller /cx. When enabled, the selftest task will be performed during a scheduled timeslot.
For "selftest" background task description, see command /cx show selftest.
Example:
//localhost>>/c2 set selftest=enable Sending commands to enable all selftests ... Done.
This command allows you to set a controller based write cache policy. If the policy is set to cacheoff, then if a unit is degraded, firmware will disable the write-cache on the degraded unit, regardless of what the unit-based policy is. If the policy is set to follow, then if a unit is degraded, firmware will follow whatever policy has been set for that unit.
This command allows you to set a controller based disk spin up policy. The value must be a positive integer between 1 and the number of disks/ports supported on the controller (e.g. 4, 8, 12, 16). This policy is used to stagger spin ups of disks at boot time in order to spread the power consumption on the power supply. For example, given a spin up policy of 2, the controller will spin up two disks at a time, pause, and then spin up another 2 disks, and so on. The amount of time to pause can be specified with the spin up stagger time policy.
Example:
//localhost>>/c2 set spinup=2 Setting Disk Spinup Policy on /c2 to [2] ... Done.
See also:
/cx show spinup /cx set stagger=nn /cx show stagger
This command allows you to set a controller based disk spin up stagger time policy. The value must be a positive integer between 0 and 60 (seconds). This policy in conjunction with disk spin up policy specifies how the controller should spin up disks at boot time.
Example:
//localhost>>/c2 set stagger=3 Setting Spinup Stagger Time Policy on /c2 to [3] ... Done.
See also:
/cx show stagger /cx set spinup=nn /cx show spinup
This command allows you to enable or disable the Drive Performance Monitor (DPM). By setting dpmstat to on you can enable the gathering of statistics for drives when I/O is running. These statistics can be helpful when troublshooting performance problems.
You can see whether the Perfromance Monitor is currently running and dispaly a statistic summary by using the command /cx show dpmstat.
The DPM is disabled by default since there is overhead in maintaining the statistics, and would be disabled following a reboot or power-on.
Note that turning off DPM does not clear the statistical data that has been recorded. To clear the data, use the command /cx/px set dpmstat=clear.
Example:
//localhost> /c0 set dpmstat=off Setting Drive Performance Monitoring on /c0 to [off]... Done.
For more information regarding the DPM and statistics gathered, please see the section on 'Drive Performance Monitor' of the Features section, or the 3ware SAS/SATA RAID Sofware User Guide, Version 9.5.1.
This command allows you to set the Auto-Carving policy to be on or off. When the Auto-Carving policy is ON, any unit larger than the carvesize is created or migrated into one or more carvesize volumes and a remaining volume. Each volume can be treated as an individual disk with its own file system. The default carvesize is 2 TB. This feature is useful for operating systems limited to 2 TB filesystems.
For example a 3 TB array would be configured into a 2 TB and a 1 TB volumes with default carvesize. For a 5 TB array, two 2 TB volumes would be created plus a 1 TB volume.
When autocarve policy is off, all the new unit creation or migration consists of one single volume.
Example:
//localhost> /c0 set autocarve=on Setting Auto-Carving Policy on /c0 to on ... Done.
See also:
/cx show autocarve /cx set carvesize=<1024..32768> /cx show carvesize`
This command allows you to set the carve size in GB. This feature works together with the autocarve above. See "/cx set autocarve=on|off" command above for details.
Example:
//localhost> /c0 set carvesize=2000 Setting Auto-Carving Size on /c0 to 2000 GB ... Done.
See also:
/cx show carvesize` /cx set autocarve=<on|off> /cx show autocarve
This command sets the Auto-Rebuild policy of the specified controller to be ON or OFF. If there is a degraded unit and the policy is set to ON, the controller firmware will choose drives in the following order of priority, for a candidate to perform the rebuild operation:
1. Smallest usable capacity spare.
2. Smallest usable unconfigured drive.
3. Smallest usable capacity failed drive.
If the policy is OFF, spares are the only candidate for the rebuild operation.
Example:
//localhost> /c0 set autorebuild=on Setting Auto-Rebuild Policy on /c0 to on ... Done.
See also:
/cx show autorebuild
This command is associated with the stagger spin-up feature during hot-plug. With stagger spin-up enabled (see command /cx set spinup and /cx set stagger), during reset or power on, the controller will try to detect all drives that are present and spin them up staggered in time, allowing the spread of power consumption on the power supply. Upon drive hot-plug, that is, not on power-on or reset, the default behavior of the system is automatic detection of the drives and immediate spin-up. This command would change the default behavior and set the controller to spin-up as the system at power-on.
The autodetect=on|off attribute configures the controller drive auto-detect setting. It should be set to off to initiate the sequence for the stagger spin-up during hot-plug process. After the drives are inserted or re-inserted to the ports (as specified in the second attribute decribed below), it should be set back to on to complete the configuration process for the controller to initiate the drive spin-up.
The disk=<p:-p>|all attribute specifies one or many disks (i.e., drives or ports). If a port is empty (i.e., no drive inserted), the echo message of the command refers to a port, and if there is already a drive inserted the message refers to a disk. The example below shows that auto detect has been set to off to initiate stagger spin-up during hot-plug, where port 3 was empty and ports 5 and 6 had drives inserted.
//localhost>> /c0 set autodetect=off disk=3:5-6 Setting Auto-Detect on /c0 to [off] for port [3] and for disk [5,6]... Done
If "disk=all", then all of the drives or ports for that controller are specified. for example:
//localhost>> /c0 set autodetect=off disk=all Setting Auto-Detect on /c2 to [off] for all disks/ports... Done.
To illustrate how the command is used, here is a usage scenario:
1. Issue command (set autodetect=off) to disable automatic detection of the
ports for staggered spin-up.
2. Pull out the drives of the specified ports (if not empty).
3. Replace the drives previously removed at the ports specified.
4. Issue command (set autodetect=on) to enable auto detect of the ports with
the newly inserted drives.
The above procedure would spin-up the newly inserted drives in a staggered manner. Please note that the command takes longer to complete for ports that do not have drives inserted.
The commands starts a media scan operation on the specified controller /cx. It provides media scrubbing for validating functionality of a disk. This includes bad block detection and remapping, etc. This command applies to 7000/8000 controllers only.
The commands stops a media scan operation on the specified controller /cx. It provides media scrubbing for validating functionality of a disk. This includes bad block detection and remapping, etc. This command applies to 7000/8000 controllers only.
Logical Disk Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a Logical Disk (a.k.a. unit) such as /c0/u0.
Note that in the output of unit information tables that follows, the column "Port" may be "VPort" depending on the applicable controller.
This command shows summary information on the specified unit /cx/ux. If the unit consists of sub-units as with RAID-10 and RAID-50 arrays, then each sub-unit is further presented. If the Auto-Carving policy was ON at the time the unit was created and the unit is over the carve size (default is 2TB-1), multiple volumes will be created and displayed at the end of the unit summary table.
The following example shows a RAID-50 (u0) and a RAID-0 (u1) array, respectively:
//localhost> /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-50 OK - - - 64K 596.05 u0-0 RAID-5 OK - - - 64K - u0-0-0 DISK OK - - p0 - 149.10 u0-0-1 DISK OK - - p2 - 149.10 u0-0-2 DISK OK - - p3 - 149.10 u0-1 RAID-5 OK - - - 64K - u0-1-0 DISK OK - - p4 - 149.10 u0-1-1 DISK OK - - p5 - 149.10 u0-1-2 DISK OK - - p6 - 149.10
//localhost> /c0/u1 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u1 RAID-0 OK - - - 64K 3576.06 u1-0 DISK OK - - p0 - 298.01 u1-1 DISK OK - - p1 - 298.01 u1-2 DISK OK - - p2 - 298.01 u1-3 DISK OK - - p3 - 298.01 u1-4 DISK OK - - p4 - 298.01 u1-5 DISK OK - - p5 - 298.01 u1-6 DISK OK - - p6 - 298.01 u1-7 DISK OK - - p7 - 298.01 u1-8 DISK OK - - p8 - 298.01 u1-9 DISK OK - - p9 - 298.01 u1-10 DISK OK - - p10 - 298.01 u1-11 DISK OK - - p11 - 298.01 u1/v0 Volume - - - - - 2047.00 u1/v1 Volume - - - - - 1529.06
One application of this command is to see which sub-unit of a degraded unit has caused the unit to degrade and which disk within that sub-unit is the source of degradation.
The unit information table shows the percentage completion of the processes associated with the unit with %RCompl (percent Rebuild completion) and %V/I/M (percent Verifying, Initializing, or Migrating).
Unlike other array types, RAID-6 may potentially have 2 or more parity drives and can tolerate two or more failures within a unit. As a result, an added notation is used to describe %RCompl and %V/I/M, and these are (A) and (P). (A) denotes that the percentage completion is for the current active process, and (P) denotes that the percentage completion is for the current paused process. For example:
/localhost> /c0 show unitstatus
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ---------------------------------------------------------------------------------- u0 RAID-6 REBUILD-VERIFY 50%(A) 70%(P) 64k 298.22 ON OFF
Here, the RAID-6 unit u0 is in the Rebuild-Verify state, with percentage Rebuild completion of 50% and is the current active process. The process of either Verifing, Initializing, or Migrating is at 70% and it is a paused process.
For the unit display:
//localhost> /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-6 REBUILD-VERIFY 50%(A) 70%(P) - 64K 2683.80 u0-0 DISK OK - - p0 - 298.20 u0-1 DISK OK - - p1 - 298.20 u0-2 DISK OK - - p2 - 298.20 u0-3 DISK REBUILDING 80% - p3 - 298.20 u0-4 DISK OK - - p4 - 298.20 u0-5 DISK OK - - p5 - 298.20 u0-6 DISK OK - - p6 - 298.20 u0-7 DISK OK - - p7 - 298.20 u0-8 DISK REBUILD-PAUSE 20% - p8 - 298.20 u0-9 DISK OK - - p9 - 298.20 u0-10 DISK OK - - p10 - 298.20 u0-11 DISK OK - - p11 - 298.20
In the above example, the RAID-6 unit u0 has 3 parity drives. Currently, it has two REBUILDING drives; one is in the active rebuilding state and another is in the paused rebuild state. The unit is also in the paused VERIFY state. Like the output of the '/cx show unitstatus' command, the top-level unit status and percentage show the composite unit status and composite rebuild percentage.
This command shows the current setting of the given attribute(s). One or many attributes can be requested. An invalid attribute will terminate the loop. Possible attributes are: initializestatus, name (9000 series), qpolicy (9550SX and higher), rebuildstatus, serial (9000 series), status, storsave(9550SX and higher), verifystatus, volumes (9000 series), autoverify, cache or wrcache, rdcache, ignoreECC, identify, rapidrecovery, and parity.
The attributes volumes, name, serial, autoverify, and ignoreECC are applicable to 9000 series controllers; the attributes qpolicy, storsave, and identify are only applicable to 9550SX and higher nodel controllers; the attribute rapidrecovery is only applicable to 9650SE and newer controllers; the attribute parity is only applicable to the RAID-6 array; and the rdcache attribute is applicable for the 9650SE (with Release 9.5.2 or later) and newer controllers.
This command reports the status of the specified unit.
Example:
//localhost> /c0/u0 show status /c0/u5 status = OK
This command reports the rebuildstatus (if any) of the specified unit.
Example:
//localhost> /c0/u5 show rebuildstatus /c0/u5 is not rebuilding, its current state is OK
This command reports the verifystatus (if any) of the specified unit.
Example:
//localhost> /c0/u5 show verifystatus /c0/u5 is not verifying, its current state is OK
This command reports the initializestatus (if any) of the specified unit.
Example:
//localhost> /c0/u5 show initializestatus /c0/u5 is not initializing, its current state is OK
This command reports the number of volumes in the specified unit.
Example:
//localhost> /c0/u5 show volumes /c0/u5 Volume(s) = 2
This command reports the name (if any) of the specified unit.
Example:
//localhost> /c0/u5 show name /c0/u5 Name = Joe
This command reports the unique serial number of the specified unit.
Example:
//localhost> /c0/u5 show serial /c0/u5 Serial Number = 12345678901234567890
This command reports the queue policy of the specified unit. If the queue policy is ON, the firmware utilizes the drive queueing policy. Some drives do not support any queueing policy, in that case this policy setting will have no effect on those drives.
For a spare unit, drive queuing is not meaningful or applicable. For example, when a spare becomes a true unit in migration, it would adopt the queue policy of the "new" unit. Thus, this commmand does not show the queue policy for the spare unit type.
Example:
//localhost> /c0/u5 show qpolicy /c0/u5 Command Queuing Policy = on
This command reports the storsave policy (protect|balance|perform) of the specified unit.
For detail, see /cx/ux set storsave=protect|balance|perform.
Example:
//localhost> /c0/u5 show storsave /c0/u5 Command Storsave Policy = protect
This command reports the identify status of the specified unit within an enclosure. If set to ON, the LEDs of the drive slots associated with the specified unit would blink.
Example:
//localhost> /c0/u0 show identify /c0/u0 Identify status = on.
See also:
/cx/ux set identify=<on|off> /cx/px set identify=<on|off> /cx/px show identify
This command reports the current autoverify setting of the specified unit.
Example:
//localhost> /c0/u0 show autoverify /c0/u0 Auto Verify Policy = off
This command reports the current write cache state of the specified unit.
Example:
//localhost> /c0/u0 show cache /c0/u0 Write Cache = on
This command reports the current read cache setting of the specified unit. The state of the read cache could be either basic, intelligent, or off. "Off" denotes that the read cache is disabled. For more information on the read cache modes of Basic and Intelligent, please see /cx/ux set rdcache.
This command is supported on the 9650SE (with Release 9.5.2 or later) and newer controllers. This feature is supported in all arrays types.
Example:
//localhost> /c0/u0 show rdcache /c0/u0 Read Cache = Intelligent
See also:
/cx/ux set rdcache=<basic|intelligent|off>
This command reports the current setting of the ignoreECC policy for the specified unit.
Example:
//localhost> /c0/u0 show ignoreECC /c0/u0 Ignore ECC policy = off
This command shows the Rapid RAID Recovery policy for the specified unit. This policy can be all, rebuild, or disable. For more information about the policy settings, please see /cx/ux set rapidrecovery=<all|rebuild|disable>.
This command only applies to the 9650SE (with Release 9.5.1) and newer controllers, as well as redundant arrays only.
For example:
//localhost> /c0/u0 show rapidrecovery /c1/u0 Rapid RAID Recovery policy setting = disable
Note: The attribute rapidrecovery in the command may be abbreviated as "rrr".
This command shows the current setting of all of the above attributes.
If the Auto-Carving policy was on at the time the unit was created and the unit is over the carve size (default is 2 TB - 1), multiple volumes will be created and will be displayed at the end of the summary information.
Example:
//localhost> /c0/u1 show all
/c0/u1 status = OK /c0/u1 is not rebuilding, its current state is OK /c0/u1 is not verifying, its current state is OK /c0/u1 is not initializing, its current state is OK /c0/u1 volume(s) = 2 /c0/u1 name = 1234567 /c0/u1 serial number = C6CPR7JMF98DA8001DF0 //localhost> /c0/u1 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u1 RAID-0 OK - - - 64K 3576.06 u1-0 DISK OK - - p0 - 298.01 u1-1 DISK OK - - p1 - 298.01 u1-2 DISK OK - - p2 - 298.01 u1-3 DISK OK - - p3 - 298.01 u1-4 DISK OK - - p4 - 298.01 u1-5 DISK OK - - p5 - 298.01 u1-6 DISK OK - - p6 - 298.01 u1-7 DISK OK - - p7 - 298.01 u1-8 DISK OK - - p8 - 298.01 u1-9 DISK OK - - p9 - 298.01 u1-10 DISK OK - - p10 - 298.01 u1-11 DISK OK - - p11 - 298.01 u1/v0 Volume - - - - - 2047.00 u1/v1 Volume - - - - - 1529.06
This command allows you to remove (or export) a unit. Exporting a unit will instruct the firmware to remove the specified unit from its pool of managed units, but retains the DCB (Disk Configuration Block) meta-data. As such the unit can later be imported back. noscan is used to not inform the OS of this change. Default is to inform the OS. The quiet option is for non-interactive mode.
Use caution when using this command. Units that are currently in use or mounted cannot be removed.
This command allows you to delete a unit. Deleting a unit not only remove the specified unit from the controller's list of managed units, but also destroys the DCB (Disk Configuration Block) meta-data. Ports (or disks) associated with this unit will now be part of the free pool of managed disks. In another words, once the unit is deleted, all the data on the unit can not be recovered. noscan is used to not inform the OS of this change. Default is to inform the OS. The quiet option is for non-interactive mode.
Use caution when using this command. This is a destructive command and should be used with extreme care. Units that are currently in use or mounted should not be deleted.
This command allows you to rebuild a DEGRADED unit by using the specified disk=p. Rebuild only applies to redundant arrays such as RAID-1, RAID-5, RAID-10 and RAID-50. During rebuild, bad sectors on the source disk will cause the rebuild to fail. You can allow for the operation to continue via ignoreECC. Rebuild process is a background task and will change the state of a unit to REBUILDING. Various show commands also show a percent completion as rebuilding progresses.
Note that the disk to be used to rebuild a unit, must be a SPARE or unconfigured disk.
This command starts a background verification process on the specified unit /cx/ux. The following shows the supported matrix as a function of controller model and logical unit type. N/A (Not Applicable) refers to cases where the given logical unit type is not supported on that controller model.
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | Raid50 | Single | JBOD | Spare | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 7K/8K | No | Yes | Yes | N/A | Yes | N/A | N/A | No | No | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9K | Yes | Yes | Yes | N/A | Yes | Yes | Yes | Yes | Yes | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9650SE | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | and | | | | | | | | | | higher | | | | | | | | | | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+
For 9550SX and earlier controllers and for 9650SE or 9690SA running pre-9.5.1, when you issue this command the specified verify will begin if the verify schedule is disabled' otherwise it will pause until the next scheduled verify.
The above also applies if you have a 9650SE or 9690SA controller running post-9.5.1, and have set verify=advanced. If verify=basic, the verify will start immediately.
This command allows you to pause the rebuild operation on the specified REBUILDING unit /cx/ux. This feature is intended for model 7000 and 8000 only. Model 9000 has an on-board scheduler where rebuild operations can be scheduled to take place at specified start and stop times.
Rebuild pause function is provided to enable 7000/8000 users to achieve
functionality with use of OS provided schedulers such as cron(8) or, at(1)
in Linux or user supplied programs.
This command allows you to resume the rebuild operation on the specified unit /cx/ux. This feature is intended for model 7000 and 8000 only. Model 9000 has an on-board scheduler where rebuild operations can be scheduled to take place at specified start and stop times.
Rebuild resume function is provided to
enable 7000/8000 users to achieve similar functionality with use of OS provided
schedulers such as cron(8) or, at(1) in Linux or user supplied programs.
This command stops a background verification process on the specified unit /cx/ux. The following shows the supported matrix as a function of controller model and logical unit type. N/A (Not Applicable) refers to cases where the given logical unit type is not supported on that controller model.
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | Raid50 | Single | JBOD | Spare | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 7K/8K | No | Yes | Yes | N/A | Yes | N/A | N/A | No | No | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9K | Yes | Yes | Yes | N/A | Yes | Yes | Yes | Yes | Yes | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9650SE | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | and | | | | | | | | | | higher | | | | | | | | | | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+
Note that if subsequent to this command, one enables the background verify task to follow the scheduled slots, then this on-demand task will be paused until the next scheduled timeslot.
This command allows you to flush the write cache on the specified unit /ux associated with controller /cx. Note that this command does not apply to spare unit types.
This command allows you to turn on/off the autoverify operation on a specified unit /cx/ux. Once the autoverify=on, the RAID firmware will pick a time to start the verify process on the unit. If the allocated schedule windows is enabled, the verify process becomes active during the scheduled windows. Otherwise, the firmware will decide when the verify needs to be paused or restarted again before it completes.
You can use the show verify command to display the existing schedule windows. The autoverify operation is a continuous verify operation, which takes place within the existing schedule windows (displayed with /cx show verify) if the schedule is enabled. While the "/cx show verify" command allows you to see the time for the verify operation, this command allows you to enable or disable the autoverify operation on the specified unit. This feature only applies to 9000 models.
For a newly created unit on the 9650SE (with Release 9.5.1 or later), 9690SA, and 9750 controllers, autoverify is set to ON by default. For earlier controller models, the default is OFF.
This command allows you to enable or disable the write cache on a specified unit /cx/ux. This feature is supported on the 7000/8000 and 9000 models. The quiet option is for the non-interactive mode, where no confirmation is requested to proceed. It can be used when the controller has no BBU installed. The following is the Raid Type-Model support matrix.
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | Raid50 | Single | JBOD | Spare | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 7K/8K | Yes | Yes | Yes | N/A | Yes | N/A | N/A | Yes | No | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9K | Yes | Yes | Yes | N/A | Yes | Yes | Yes | Yes | No | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ 9650SE | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | and | | | | | | | | | | higher | | | | | | | | | | --------+-------+-------+-------+-------+--------+--------+--------+------+-------+
This command allows you to set the read cache to either basic, intelligent, or off on a specified unit.
Read Cache Basic is used to store data locally on the controller that has recently been written to media and is likely to be frequently accessed. This improves read access times for applications such as a database that can take advantage of storage caching. Read cache may be disabled without reducing performance for applications that are write intensive, or infrequently read back data recently written.
Read Cache Intelligent enables the Intelligent Read Prefetch (IRP) feature. This new feature includes a typical read ahead caching method, which is used to proactively retrieve data from media and store it locally on the controller with the anticipation that it may be requested by the host. For example, the host may read blocks 1, 2, and 3. With read-ahead caching, the controller will also retrieve and hold in its cache blocks 4, 5, and 6 in anticipation of getting those command requests from the host. By loading a larger set of data into the cache, chances are improved that another request can be filled by data that is already in the cache. This can be helpful with applications that are sequential in nature, such as video on demand, video surveillance playback, and restoring from a disk-to-disk backup. Performance benefits of read-ahead are especially pronounced when the host queue depth is low. In addition, read-ahead cache also improves sequential read performance when the unit is degraded. The Intelligent Read Prefetch (IRP) feature also includes some intelligent and adaptive stream management layer to improve performance at higher queue depth in multiple read only or mixed read/write stream environments. The performance improvements should be seen for most type of arrays and in any modes.
Note: If Intelligent mode is enabled, the features in Basic mode are also enabled.
The following table provides some recommendations for when to use each Read Cache setting.
------------------------------------------------------------------------
USE THIS READ CACHE | FOR THIS REASON | EXAMPLE APPLICATIONS
SETTING | |
------------------------------------------------------------------------
Intelligent | Sequential applications, | Video on Demand,
| with a low host command | Video Surveillance
| command queue depth | Playback
| | Disk-to-Disk Backup
| | Restores, File Server
------------------------------------------------------------------------
Basic | Frequent access to | Database
| recently written data |
| |
| |
| |
------------------------------------------------------------------------
Disabled | Applications that | Online Transaction
| a high queue depth or | Processing (OLTP)
| perform their own read- |
| ahead can generate |
| enough I/O to negate the |
| benefits of controller |
| read caching or read- |
| ahead. This is |
| especially true for apps |
| that produce a large |
| a lot of random I/O. |
------------------------------------------------------------------------
This command is supported on the 9650SE (with release 9.5.2 or later) and newer controllers. This feature is supported for all arrays types.
Example:
//localhost> /c0/u0 set rdcache=intelligent Setting Read Cache Policy on /c0/u0 to [intelligent] ... Done.
This command allows you to identify a unit within an enclosure. If set to ON, the LEDs of the drive slots associated with the specified unit would blink.
Example:
//localhost> /c0/u0 set identify=on Sending Identify request for unit /c0/u0 to [on] ... Done.
See also:
/cx/ux show identify /cx/px show identify /cx/px set identify=<on|off>
This command allows you to set the ignoreECC policy for a given unit such that during rebuild of the specified unit, which could begin automatically (if the unit is degraded and spare has been defined) or manually, to be applied to the rebuild operation. Setting overwriteECC to on means ignoreECC. This feature only applies to 9000 models.
This command allows you to name the unit to an arbitrary name upto 21 characters. No space is allowed within the string. If user likes to use some special characters which the OS command shell reserves such as '<', '>', '!', and '&', etc in the name string, the user has to use quote "" around the name string in order to bypass the command shell. Users can use this name in conjunction with the unit serial number (which created at the unit creation time) to cross reference with the unit. It is user's responsibility to give unique or redundant names on all units. This feature only applies to 9000 models.
This command presents the queue policy of the firmware. If the queue policy is on, the firmware utilizes the drive queueing policy. Some drives do not support any queueing policy, this policy will have no effect on those drives.
For a spare, drive queuing is not meaningful or applicable. For example, when a spare undergo unit migration and becomes a true unit, it adopts the queue policy of the "new" unit. Thus, this commmand does not set the queue policy for the unit type spare.
Example:
//localhost> /c0/u5 set qpolicy = on Setting Command Queuing Policy for unit /c0/u5 to [on] ... Done.
This command sets the Rapid RAID Recovery policy for the specified unit. Rapid RAID Recovery can speed up the rebuild process, and it can speed up the initialize and verify tasks for redundant arrays in the RAID system upon the event of an unclean system shutdown. This feature allows for expedited boot-up time in the event of an unclean shutdown. Setting this option to all applies the policy to the rebuild, initialize and verify tasks at reboot. Setting it to rebuild applies the policy to the rebuild tasks only. If the policy is set to disable, then none of the tasks would be sped up. (Note: In the command "rapidrecovery" may be abbreviated as "rrr".)
Note: The default setting of Rapid RAID Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled.
Note: There is a quiet option for setting the Rapid RAID Recovery policy to disable. The quiet option is provided for scripting purposes and is applicable to the disable setting only.
For example:
//localhost> /c0/u0 set rapidrecovery=all Setting Rapid RAID Recovery policy on /c1/u0 to [all] ... Done.
Note: Rapid RAID Recovery is not supported over migration.
This command sets the storsave policy of the specified unit to be either protect, balance, or perform when the unit write cache is enabled.
This feature is available for the 9550SX and higher model controllers only. There is a tradeoff among the available settings. The following description about the settings should help you to decide which one is suitable for your applications. The protect mode is the default setting.
protect -- provides the maximum data protection among the controller settings. When user sets storsave to protect, it means:
1. "Write Cache" will be disabled when the unit becomes "DEGRADED",
2. all data flushing from controller cache will be flushed to media, and
3. incoming FUA (Force Unit Access) host request will be ignored if a BBU is installed and enabled; Otherwise, will be honored.
perform -- provides the maximum performance and less data protection among the controller settings. When user sets storsave to perform, it means:
1. "Write Cache" will not be disabled when the unit becomes "DEGRADED",
2. all data flushing from controller cache will be flushed to disk, and
3. incoming FUA (Force Unit Access) host request will be honored.
Note: When storsave is set to perform, a warning about data loss in the event of power failure is displayed, followed by a prompt to continue. If you want to skip the confirmation, use the [quiet] option to bypass.
balance -- provides more data protection than perform mode but less data protection than protect mode, and provides better performance than protect mode but less performance than perform mode. When user sets the storsave to balance, it means:
1. "Write Cache" will not be disabled when the unit becomes "DEGRADED",
2. all data flushing from controller cache will be flushed to media if a BBU is installed and enabled; Otherwise, will be flushed to disk only, and
3. incoming FUA (Force Unit Access) host request will be ignored if a BBU is installed and enabled; Otherwise, will be honored.
Example:
//localhost> /c0/u5 set storsave=protect Setting Command Storsave Policy for unit /c0/u5 to [protect] ... Done.
This feature is only available with 9000 series of controllers.
This command allows you to migrate an existing unit (aka source) to a unit with type=RaidType (aka destination), to increase capacity, change the RAID level (with the same or increased capacity), or change the stripe size.
The unit that results from the migration (destination unit) is subject to similar rules and policies that apply when creating a new unit. For example, a valid number of disks and parameters must be specified. The destination unit must use all source disks and potentially augment the number of disks in the disk=p:-p disk list. Unspecified parameters are assigned default values (stripe size of 64K, write cache enabled, autoverify disabled, and ignoreECC disabled).
The unit to be migrated (source unit) must be in a normal state (not degraded, initializing, or rebuilding) before the migration. If the source unit is of type RAID-1 and the destination unit is of type single, the disk-specifier of the migration command [disk=p:-p] is actually not optional and must not be included in the command. The drives in the RAID-1 array would become multiple units of type single after the migration, and the source drives are the destination drives. Specifying more drives with the "disk=" option would return an error.
Both source unit name and serial number will be carried over to the destination unit. However, the RAID-1 to single migration path is a special case. In this case, the migrate command splits both drives into two identical single disks. The source unit name will be duplicated on the destination units, or single disks, but the source unit serial number will not be carried over to new unit. The new destination unit will have its own serial number.
type=RaidType consists of the destination unit RAID type as in raid0, raid1, raid5, raid10, raid50, raid6, or single.
For example "type=raid5" indicates the destination unit is RAID-5.
The following table illustrates valid migration paths:
Src/Dst | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare | Raid6 | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid0 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid1 | Y | N | Y | Y | Y | Y | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid5 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid10 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid50 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Single | Y | Y | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ JBOD | N | N | N | N | N | N | N | N | N | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Spare | N | N | N | N | N | N | N | N | N | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid6 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Note: You can only migrate a unit to a RAID level that has the same or larger capacity as the exisiting one. A four-drive RAID-5 unit can migrate to a four-drive RAID-0, but a four-drive RAID-0 unit cannot migrate to a four-drive RAID-5, without adding another drive, due to the need for additional storage capacity for parity bits.
disk=p:-p consists of a list of ports or vports (disks) to be used in addition to the source disks in the construction of the destination unit. One or more ports can be specified. Multiple ports can be specified using ":" or "-" as port index separators. A dash indicates a range and can be mixed with ":". For example disk=0:1:2-5:9:12 indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12.
group=3|4|5|6|7|8|9|10|11|12|13|14|15|16 is only applicable to type=raid50 which consists of a number of disks per group. Recall that a RAID-50 is a multi-tier array. At the most bottom layer, N number of disks per group are used to form the RAID-5 layer. These RAID-5 arrays are then integrated into a RAID-0. This option allows you to specify the number of disks in the RAID-5 level. Valid values are 3, 4, 5 and 6. For example group=3 indicates 3 disks of RAID-5 at the bottom layer of RAID-50.
Note: You can have a maximum of 4 subunits in a RAID-50 unit.
Note that a sufficient number of disks are required for a given pattern or disk group. For example, given 6 disks, specifying 3 will create two RAID-5. However given 12 disks, specifying 3 will create four RAID-5 under the RAID-0 level. Given 6 disks and grouping of 6 is not allowed, as you'll basically be creating a RAID-5.
The default disk group varies based on number of disks. For 6 & 9 disks, default is group=3. For 8 disks, default is group=4. For 10 or 15 disks, default is group=5. For 12 or 16 disks, default is group=4. For 14 disks, default is group=7. Case of 12 disks could be grouped with group=3, group=4, or group=6. Group=4 was set by default as it provides best net capacity and performance. Case of 15 disks could be grouped with group=3 or group=5. And case of 16 disks could be grouped with group=4 and group=8.
Note that RAID-10 always has group=2, so an attribute specifying its group is not necessary.
Stripe consists of the logical unit stripe size to be used. The following table illustrates the supported and applicable stripes on the respective unit types and controller models. Stripe size units are in KB (kilobytes).
Model | Raid0 | Raid1 | Raid5 | Raid6 | Raid10 | Raid50 | JBOD | Spare | Single |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
9K | 16 | N/A | 16 | N/A | 16 | 16 | N/A | N/A | N/A |
| 64 | | 64 | | 64 | 64 | | | |
| 256 | | 256 | | 256 | 256 | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
9650SE| 16 | N/A | 16 | | 16 | 16 | N/A | N/A | N/A |
and | 64 | | 64 | 64 | 64 | 65 | | | |
higher| 256 | | 256 | 256 | 256 | 256 | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+
noscan instructs CLI not to notify the operating system (OS) about the creation of the new unit. By default CLI will inform the OS. One application of this feature is to prevent the OS from creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and a moving target.
nocache instructs CLI to disable the write cache on the migrated unit. Enabling write cache increases performance, but at the cost of potential data loss in the event of sudden power loss (unless a BBU or UPS is installed). By default the cache is enabled. Unless there is a BBU or UPS installed, to avoid the possibility of data loss in the event of sudden power loss, it is recommended that nocache be specified.
autoverify enables the autoverify attribute on the unit to be migrated. For more details on this feature, refer to cx/ux set autoverify section of this document.
Migration Process. In all cases of migration, the background migration process must be completed before the newly sized unit is available for use. You can continue using the original unit during this time. Once the migration is finished, a reboot will be required if you are booted from the unit. For secondary storage, depending on your operating system, you may need to first unmount the unit, then use CLI to 'remove' and 'rescan' the unit so that the operating system can see the new capacity, and then remount the unit.
You may also need to resize the file system or add a new partition. For instructions, consult the documentation for your operating system.
Note: It is important that you allow migration to complete before adding drives to the unit or move it to another controller. Making any physical changes to the unit during migration may cause the migration to stop, and can jeopardize the safety of your data.
Examples. The two examples which follow show the usage of this command for splitting a mirror and for capacity expansion, respectively. Following those are sample outputs of the migrate function. After which example outputs showing the special case are presented.
Example of split mirror:
//localhost> /c1/u3 migrate type=single Sending migration message to /c1/u3 ... Done.
The source unit u3 is a TWINSTOR or RAID-1, using the migrate command splits u3 to u3 and ux, each with the RAID type of Single.
Example of capacity expansion:
//localhost> /c0/u3 migrate type=raid10 disk=10-11 stripe=16 Sending migration message to /c0/u3 ... Done.
The source unit is u3 and the destination unit is RAID-10 with disks 10 and 11 in addition to the disks in the existing unit u3.
The following is an example of how migrating units are displayed. In this example, the set of reports indicate that /c0/u3 is a migrating unit with 39% completion. The "/c0/u3 show" command shows that the source unit is su3 and is of type RAID-1, and the destination unit du3 is of type RAID-10.
3ware CLI> /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 596.004 ON OFF u2 SPARE OK - - - 149.042 - OFF u3 Migrator MIGRATING - 39 - 149.001 ON OFF
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 WD-WCANM1771318 p1 OK u0 149.05 GB 312581808 WD-WCANM1757592 p2 OK u0 149.05 GB 312581808 WD-WCANM1782201 p3 OK u0 149.05 GB 312581808 WD-WCANM1753998 p4 OK u2 149.05 GB 312581808 WD-WCANM1766952 p5 OK u3 149.05 GB 312581808 WD-WCANM1882472 p6 OK u0 149.05 GB 312581808 WD-WCANM1883862 p7 OK u3 149.05 GB 312581808 WD-WCANM1778008 p8 OK - 149.05 GB 312581808 WD-WCANM1770998 p9 NOT-PRESENT - - - - p10 OK u3 149.05 GB 312581808 WD-WCANM1869003 p11 OK u3 149.05 GB 312581808 WD-WCANM1762464
3ware CLI> /c0/u3 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u3 Migrator MIGRATING - 39 - - -
su3 RAID-1 OK - - - - 149.001 su3-0 DISK OK - - p5 - 149.001 su3-1 DISK OK - - p7 - 149.001 su3/v0 Volume - - - - - 149.001
du3 RAID-10 OK - - - 16K 298.002 du3-0 RAID-1 OK - - - - - du3-0-0 DISK OK - - p5 - 149.001 du3-0-1 DISK OK - - p7 - 149.001 du3-1 RAID-1 OK - - - - - du3-1-0 DISK OK - - p10 - 149.001 du3-1-1 DISK OK - - p11 - 149.001 du3/v0 Volume - - - - - 149.001
Please note that the migration path of raidtype Single to RAID-1 is a special case. Since the single unit would become a mirrored array, technically this is not a migration. As a result this command shows a different status than other migration paths. In addition, the status of the newly specified disk would show DEGRADED until the "migration" is complete.
For example, below is a system with two migrating units, /c0/u0 and /c0/u1. u0 is migrating from a RAID-10 to a RAID-0 array, while u1 is migrating from Single to a RAID-1, initiated by the following commands:
/c0/u0 migrate type=raid0
and
/c0/u1 migrate type=raid1 disk=5
Note the difference in 'UnitType' and 'Status' of u0 and u1, even though they are both migrating units.
3ware CLI> /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 Migrator MIGRATING - 26 - 298.002 ON OFF u1 RAID-1 REBUILD-PAUSED 0 - - 372.519 OFF OFF
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 WD-WCANM1883862 p1 OK u0 149.05 GB 312581808 WD-WCANM1754124 p2 OK u0 372.61 GB 781422768 WD-WMAMY1661939 p3 OK u0 372.61 GB 781422768 WD-WMAMY1579179 p4 OK u1 372.61 GB 781422768 WD-WMAMY1662720 p5 DEGRADED u1 372.61 GB 781422768 WD-WMAMY1576310 p6 NOT-PRESENT - - - - p7 NOT-PRESENT - - - -
3ware CLI> /c0/u3 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 Migrator MIGRATING - 26 - - -
su0 RAID-10 OK - - - 64K 298.002 su0-0 RAID-1 OK - - - - - su0-0-0 DISK OK - - p0 - 149.001 su0-0-1 DISK OK - - p1 - 149.001 su0-1 RAID-1 OK - - - - - su0-1-0 DISK OK - - p2 - 149.001 su0-1-1 DISK OK - - p3 - 149.001 su0/v0 Volume - - - - - 298.002
du0 RAID-0 OK - - - 64K 596.004 du0-0 DISK OK - - p3 - 149.001 du0-1 DISK OK - - p2 - 149.001 du0-2 DISK OK - - p1 - 149.001 du0-3 DISK OK - - p0 - 149.001 du0/v0 Volume - - - - - N/A
3ware CLI> /c0/u1 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u1 RAID-1 REBUILD-PAUSED 0 - - - 372.519 u1-0 DISK OK - - p4 - 372.519 u1-1 DISK DEGRADED - - p5 - 372.519 u1/v0 Volume - - - - - 372.519
Port Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a disk which attaches to a port or vport such as /c0/p0. Note: All references of port also applies to vport for the commands in this section.
This command shows summary information on the specified disk attached to port /cx/px. Here is the typical output for controller models up to 9550SX and 9650SE with Release 9.5.1 or earlier:
//localhost> /c0/p5 show
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p5 OK u5 149.05 GB 312581808 WD-WMACK1406498
This drive summary table indicate that port p5 of controller c0 is attached to one Western Digital disk with status OK and is a part of unit u5.
For the 9650SE (with Release 9.5.2 or later), 9690SA, and 9750, the summary information on the specified disk attached to vport /cx/px has a slightly different format. Here is a sample output:
//localhost> /c3/p1 show
VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p1 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1a
In this output of the drive summary, the drive type, controller phy number, enclosure slot if applicable, and model of the drive are also displayed. (Please note the Block and Serial information could be obtained with the specific show attribute command, or the "show all" command.) Please also note that the port handle as a virtual port is indicated by the heading or column "VPort".
The drive status in the column "Status" may display different message strings depending on the detected state of the drive. This is a list of the possible statuses:
OK - Drive is operating normally. NOT-SUPPORTED - Drive is not supported. ECC-ERROR - An ECC error has been detected. SMART-FAILURE - A SMART failure has been detected. DEVICE-ERROR - A device error has been detected with the drive. READ-TIMEOUT - A DCB read timeout error has been detected. READ-FAILURE - A DCB read failure is encountered. ORPHAN - The drive contains an orphan DCB. DCB-DATA-CHECK - A DCB data check is in progress. UNSUPP-DCB - Drive contains unsupported DCB. UNCONV-DCB - Drive contains unconverted DCB. DRIVE-REMOVED - Drive has been removed. OFFLINE-JBOD - Drive is an offline JBOD. NOT-PRESENT - Drive is offline. CFG-OP-FAIL - A drive configuration operation failure is encountered. POR-OCCURRED - A power-on-reset has occurred. UNKNOWN - The condition or error encountered is not reportable.
This command shows the current setting of the given attribute(s) on the specified port or disk. One or many attributes can be requested. Invalid attribute will terminate the loop. Possible attributes are: status, model, firmware, serial, capacity, smart, and the following attributes (grouped accordingly to applicability for specified controllers):
CONTROLLER | ATTRIBUTES -------------------+--------------------------------------------- 9550SX and higher | ncq, identify, lspeed, driveinfo -------------------+--------------------------------------------- 9650SE and higher | rasect, pohrs, temperature, spindlespd -------------------+--------------------------------------------- 9690SA and 9750 | driveinfo, ports, connections, drvintf, wwn -------------------+---------------------------------------------
This command reports the status of the drive associated with the specified port.
Example:
//localhost> /c0/p5 show status /c0/p5 Status = OK
Note: This command returns the status pertaining to the drive of the specified port only. Its intended use is not for determining the status of a drive relative to a unit (for that, please use '/cx/px show'). For example, if a unit is DEGRADED and a drive is the degradation point of that unit, the output of this command would not show DEGRADED as the command '/cx/px show' would. Note the difference also that this command shows status of the drive only, and does not contain other information such as unit, type, size, etc.
This command reports the model of the drive associated with the specified port.
Example:
//localhost> /c0/p5 show model /c0/p5 Model = WDC WD1600BB-00DAA0
This command reports the serial number of the drive associated with the specified port.
Example:
//localhost> /c0/p5 show serial /c0/p5 Serial = WD-WMACK1406498
This command reports the firmware version of the drive associated with the specified port.
Example:
//localhost> /c0/p5 show firmware /c0/p5 Firmware Version = 65.13G65
This command reports the identify status of the specified port within an enclosure. The LED of the drive slot associated with the specified port would blink if the identify status is ON.
Example:
//localhost> /c0/p5 show identify /c0/p5 Identify Status = on
This command reports the NCQ (Native Command Queueing) information of the drive associated with the specified port.
Example (9550SX):
//localhost> /c0/p5 show ncq /c0/p5 NCQ Supported = No /c0/p5 NCQ Enabled = No Example (9690SA):
//localhost> /c3/p0 show ncq /c3/p0 Queuing Supported = Yes /c3/p0 Queuing Enabled = Yes
This command reports 1) the SATA link speed supported by the drive associated with the specified port and 2) the actual link speed that the specified port is set to.
Example:
//localhost> /c0/p5 show lspeed /c0/p5 SATA Link Speed Supported = 3.0 Gb/s /c0/p5 SATA Link Speed = 3.0 Gb/s
This command reports the capacity of the drive associated with the specified port in gigabytes (GB) and in block count. The capacity in GB is computed based on division by 1000 and not 1024, as is popular with hard disk vendors.
Example:
//localhost> /c0/p5 show capacity /c0/p5 Capacity = 149.05 GB (312581808 Blocks)
This command extracts SMART (Self Monitoring Analysis and Reporting) data from the specified SATA disk. Note that this data is actually extracted live and as such this command could be used to get most recent data about the presence of a disk. Be aware that extracting SMART data will burden the I/O bandwidth.
Note: SMART data is applicable for SATA drives only. Therefore, a request for SMART data for a SAS drive (as with the 9690SA and 9750 controllers) would result in an error response.
Note: For SAS drives, drive attributes that could be extracted from SMART data is available with the following commands:
/cx/px show temperature /cx/px show spindlespd /cx/px show rasect /cx/px show pohrs
for temperature, spindle speed, reallocated sectors, and power-on hours, respectively. You may also use '/cx/px show all' for all of the drive attributes.
Example (9550SX):
//localhost> /c0/p5 show smart
10 00 01 0F 00 C8 C8 00 00 00 00 00 00 00 03 03 00 DA B5 34 08 00 00 00 00 00 04 32 00 64 64 88 00 00 00 00 00 00 05 33 00 C7 C7 01 00 00 00 00 00 00 07 0F 00 C8 C8 00 00 00 00 00 00 00 09 32 00 42 42 2A 63 00 00 00 00 00 0A 13 00 64 64 00 00 00 00 00 00 00 0B 12 00 64 64 00 00 00 00 00 00 00 0C 32 00 64 64 88 00 00 00 00 00 00 BE 22 00 3A 2F 2A 00 00 00 00 00 00 C2 22 00 69 5E 2A 00 00 00 00 00 00 C4 32 00 C7 C7 01 00 00 00 00 00 00 C5 12 00 C8 C8 00 00 00 00 00 00 00 C6 10 00 C8 C8 00 00 00 00 00 00 00 C7 3E 00 C8 C8 01 00 00 00 00 00 00 C8 09 00 C8 C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 00 74 13 01 7B 03 00 01 00 02 3C 06 00 00 00 00 00 00 00 00 00 00 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85
Note that if the disk attached to the specified port is not present or if there is a connection or cabling problem to the disk, CLI will return an error.
This command reports drive and connection information about the drive that is associated with the specified port.
Example:
//localhost> /c3/p4 show driveinfo
/c3/p4 Drive Type = SAS /c3/p4 Interface Type = Direct /c3/p4 Drive Ports = 2 /c3/p4 Drive Connections = 1
This command shows the current setting of all above attributes.
This command allows you to request for drive statistics of the specified type for the specified port. The 'type' in the command specifies which statistics would be displayed. The options are either: inst for Instantaneous, ra for Running Average, lct for Long Command Times, histdata for Histogram Data, and ext for Extended Drive Statistics. More detailed information regarding these statistics and the Drive Performance Monitor is available in the Features section under 'Drive Performance Monitor'.
A request for the Running Average statistics, for example:
//localhost> /c0/p3 show dpmstat type=ra
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
---------------------------------------------------------------------
p3 OK u0 0 435 25.249 2
Or for the Long Command Times statistics, for example:
//localhost> /c0/p3 show dpmstat type=lct
Port Status Unit ------------------------------ p3 OK u0
Resp
Date Time Time(ms) --------- CDB / ATA Task File (hex) -----------
------------------------------------------------------------------------------
2007-02-09 13:47:57 383.216 00 80 60 40 92 9f 8a 40 1a 00 00 00 00 00 00 00
2007-02-09 13:47:57 390.809 00 80 60 40 13 eb 30 40 26 00 00 00 00 00 00 00
2007-02-09 13:47:57 405.478 00 80 60 40 61 11 20 40 26 00 00 00 00 00 00 00
2007-02-09 13:47:57 410.379 00 80 60 40 cd 8b b9 40 23 00 00 00 00 00 00 00
2007-02-09 13:47:57 419.002 00 80 60 40 5e df d1 40 29 00 00 00 00 00 00 00
2007-02-09 13:47:57 444.250 00 80 60 40 8b c0 36 40 2e 00 00 00 00 00 00 00
2007-02-09 13:47:57 527.994 00 80 60 40 6e a5 b6 40 03 00 00 00 00 00 00 00
2007-02-09 13:47:57 569.429 00 80 60 40 3b e2 02 40 2d 00 00 00 00 00 00 00
2007-02-09 13:47:57 609.526 00 80 60 40 27 1c e9 40 2b 00 00 00 00 00 00 00
2007-02-09 13:47:57 612.051 00 80 60 40 dd 0b d1 40 2c 00 00 00 00 00 00 00
For examples of other statistic data types, please see "Drive Performance Monitor" in the 'Features' section.
This command allows you to remove (or export) a port /cx/px (or drive). Exporting a port will instruct the firmware to remove the specified port from its pool of managed ports, but retains the DCB (Disk Configuration Block) meta-data on the attached disk. You can import (or re-introduce) the port via the rescan command. Use noscan to bypass informing the OS of this change. Default is to inform the OS. The quiet option is for the non-interactive mode.
Use caution when using this command. Drives, which are part of a redundant array, can be removed, but the array will be degraded. Non-redundant drives, which are part of a unit, can not be removed.
This command sets the identify status of the specified port within an enclosure. If set to ON, the LED of the drive slot associated with the specified port would blink.
Example:
//localhost> /c0/p5 set identify=on Setting Port Identify on /c0/p5 to [on] ... Done.
This command clears the statistics counters of the Drive Performance Monitor. The optional 'type' in the command specifies which set of statistics data would be cleared. The options are either: ra for Running Average, lct for Long Command Times,and ext for Extended Drive Statistics. More detailed information regarding these statistics and the Drive Performance Monitor is available in the Features section under 'Drive Performance Monitor'.
Please note that if type=ra, both the Running Average and Histogram data are cleared. If type=lct, only the Long Command Times data would be cleared. And if type=ext, the extended drive statistics are cleared. If no type is specified, the default is the same as type=ra.
Here is an example of clearing the Running Average and Histdata statistics:
//localhost> /c0/p3 set dpmstat=clear type=ra Clearing Drive Performance Monitor running average data on /c0/p3 ... Done. Please note this clears the Running Average and Histogram data.
If I/O traffic to the drive has been stopped, after clearing, a subsequent request to show the running average statistics would show all zeros. For example:
//localhost> /c0/p3 show dpmstat type=ra
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
---------------------------------------------------------------------
p3 OK u0 0 0 0.000 0
Similarly, the display for Histogram data would show all zeros.
For examples of other statistic data types, please see 'Drive Performance Monitor' in the 'Features' section.
Phy Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller phy such as /c0/phy0.
This command is for the 9650SE with Release 9.5.2 or later, and 9690SA and newer controllers only. This command presents a summary report on the specified phy. The 'Device Type' column indicates whether the connected device is an enclosure, or a drive of type SATA or SAS. The 'Device' column is the device ID or handle. There are three 'Link Speed' columns: 'Supported' denotes the link speed capability of the phy/device, 'Enable' denotes the current link speed setting, and 'Control' denotes the link control setting. Note that the Supported and Enabled values are not changeable. The Control value is the link speed that may be set with the '/cx/phyx set link' command.
Example:
//localhost> /c3/phy0 show
Device --- Link Speed (Gbps) ---
Phy SAS Address Type Device Supported Enabled Control
-----------------------------------------------------------------------------
phy0 2007020800153811 SATA /c3/p1 1.5-3.0 3.0 1.5
This command is for the 9650SE (with Release 9.5.2 or higher), and the 9690SA controllers only. This command sets the link speed of the specified phy. The unit of link speed is in gigabits per second (Gbps). The default is auto.
Example:
//localhost> /c0/phy0 set link=1.5 Setting Link Speed Control on /c0/phy0 to [1.5 Gbps] ... Done. The link speed change will take effect after system reboot.
Note: After link speed control is set to a different value, it is necessary to reboot the controller for the new link speed to take effect.
See alo:
/cx show phy /cx/phyx show
This command is for the 9750 controller only. This command sets the link speed of the specified phy. The unit of link speed is in gigabits per second (Gbps). The default is auto.
Example:
//localhost> /c0/phy0 set link=6.0 Setting Link Speed Control on /c0/phy0 to [6.0 Gbps] ... Done. The link speed change will take effect after system reboot.
Note: After link speed control is set to a different value, it is necessary to reboot the controller for the new link speed to take effect.
See alo:
/cx show phy /cx/phyx show
BBU (Battery Backup Unit) Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a BBU such as /c0/bbu. The commands in this section are available on 9000 series controllers where the BBU is installed.
This command reports summary information on the specified BBU object.
Example:
//localhost> /cx/bbu show
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On No Testing OK OK 72 01-Jul-2009
This summary shows that the date the battery capacity was last measured is 01-Jul-2009. The battery is estimated to last for 72 hours from the last tested date. The BBU unit is currently testing the battery. Both voltage and temperature are normal. The BBU is not ready for backup of the write cache on the controller due to the testing.
This command shows the current setting of the given attribute(s) on the BBU board. One or many attributes can be requested. Invalid attribute will terminate the loop. Possible attributes are: batinst, bootloader, cap, fw, lasttest, pcb, ready, serial, status, tempstat, tempval, and volt.
This command shows the status of the BBU. Possible values are:
Testing
Battery test is currently in progress. It may take up to 24 hours to complete. During the test, the BBU is not capable of backup operation and the write cache of the applicable RAID units are also disabled. If the test is completed with no error and the BBU returns back to WeakBat or OK state, the write cache will be resumed. If a Fault, Failed or an Error occurs during the test, the write cache remains at the disabled state until the problem is fixed.
Charging
BBU is currently charging the battery. The charging is started automatically by the BBU whenever necessary. During the charging, the BBU is not capable of backup operation and the write cache is disabled. Once charging is completed and the BBU returns back to OK status, the write cache will be resumed. If a FAULT or an ERROR occurs during the test, the write cache remains at the disabled state until the problem is fixed.
Fault
A battery fault is detected. At this state, the BBU is not capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the BBU board to fix the problem as soon as possible so that the write cache will be enabled again.
Error
Other BBU error is detected. At this state, the BBU is not capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the BBU board to fix the problem as soon as possible so that the write cache will be enabled again.
Failed
The battery failed a test. At this state, the BBU is not capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the BBU board to fix the problem as soon as possible so that the write cache will be enabled again.
WeakBat
BBU is functioning normally which means it is online and capable of backing up the write cache. But the battery is weak and should be replaced.
OK
BBU is ready, online and capable of backing up the write cache.
-
Battery is not present or BBU unit is not installed.
This command reports the date when the current battery was installed.
This command reports the date the battery capacity was last measured.
This command reports the voltage status of the battery. The status can be OK, HIGH, LOW, TOO-HIGH, and TOO-LOW. The HIGH and LOW are in warning range. TOO-HIGH and TOO-LOW are out of the operating range and need to be concerned.
This command reports the temperature status of the battery. The status can be OK, HIGH, LOW, TOO-HIGH, and TOO-LOW. The HIGH and LOW are in warning range. TOO-HIGH and TOO-LOW are out of the operating range and need to be concerned.
This command reports the detected temperature value in the battery.
This command reports the battery capacity in hours.
This command reports the BBU serial number.
This command reports the BBU board firmware version number.
This command reports the PCB revision number on the BBU unit.
This command reports the BBU's Boot Loader version.
This command shows the current settings of all above attributes on the BBU board.
Example:
//localhost> /c1/bbu show all
/c1/bbu Firmware Version = BBU: 1.04.00.007 /c1/bbu Serial Number = Engineering Sample. /c1/bbu Online State = On /c1/bbu BBU Ready = Yes /c1/bbu BBU Status = OK /c1/bbu Battery Voltage = OK /c1/bbu Battery Temperature = OK /c1/bbu Estimated Backup Capacity = 241 Hours /c1/bbu Last Capacity Test = 22-Jun-2004 /c1/bbu Battery Intallation Date = 20-Jun-2004 /c1/bbu Bootloader Version = BBU 0.02.00.002 /c1/bbu PCB Revision = 65
This command starts the battery capacity test. The test may take up to 24 hours to complete. During the test, the BBU is not capable of backup operation and the write cache is disabled. The performance of all units under the controller may be impacted because their write IOs are not cached. Once the test is completed with no error and the BBU returns back to OK state, the write cache will be resumed. The quiet option is for non-interactive mode.
After the test has initiated, check the controller alarms for any AENs (Asynchronous Event Notifications) about the status of the test operation.
Note: The test cannot be terminated before it completes.
This command enables BBU detection on the controller. The controller will utilize BBU functionality in the event of power failure if BBU is there and ready.
This command disables BBU detection on the controller. The controller ignores the existence of the BBU when BBU detection is disabled. In another words, despite a BBU being attached to a controller, with BBU detection disabled, storage management software will report that there is no BBU installed on this controller. The quiet option is for non-interactive mode.
Enclosure Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of an enclosure such as e0. The enclosure element object messages are commands sent to an instance of the enclosure element such as fan0. The subsections which follow describe the commands of the enclosure and the enclosure elements. The latter includes commands for the slot, fan, temperature sensor, and power supply elements.
The command descriptions and examples of this section are shown with the syntax of the controller object pre-pended to the enclosure object (i.e., /cx/ex). For systems with the 9650SE controller or CCU enclosure, simply drop the pre-pended controller name in the command, as, not '/c1/e0' but '/e0'.
The following table summarizes the supported controllers, protocols, configurations, and enclosure elements.
--------------------------+------------------------------------------
Controller -> | 9650SE | 9690SA and above
--------------------------+------------------------------------------
Configuration/Protocol -> | CCU/SAF-TE | SES-2 | SES-2
--------------------------+------------+-----------+-----------------
Syntax -> | /ex | /ex | /cx/ex
-----------+--------------+------------+-----------+-----------------
| Slot | Y | Y | Y
|--------------+------------+-----------+-----------------
| Fan | Y | Y | Y
Enclosure |--------------+------------+-----------+-----------------
Elements | Temp Sensor | Y | Y | Y
Supported |--------------+------------+-----------+-----------------
| Power Supply | N | Y | Y
|--------------+------------+-----------+-----------------
| Alarm | N | Y | Y
-----------+--------------+------------+-----------+-----------------
This command shows summary information on the specified enclosure /ex, along with the elements supported or associated with the specified enclosure. This report consists of several parts, depending on the available elements of the enclosure. Typically, the summary consists of an Enclosure section, a Fan section, a Temperature Sensor section, and a Slot section.
Typical output looks like:
//localhost> /c0/e0 show
Encl Status --------------------------- /c0/e0 OK
Fan Status State Step RPM Identify ------------------------------------------------------------ fan0 OK ON 1 2670 Off fan1 OK ON 1 9500 Off fan2 OK ON 1 8540 Off fan3 OK ON 1 2830 Off fan4 OK ON 1 9120 Off fan5 OK ON 1 8330 Off
TempSensor Status Temperature Identify -------------------------------------------------------- temp0 OK 41C(105F) Off temp1 OK 38C(100F) Off temp2 OK 34C(93F) Off temp3 OK 38C(100F) Off temp4 OK 38C(100F) Off temp5 OK 34C(93F) Off temp6 NOT-INSTALLED - Off temp7 NOT-INSTALLED - Off
PowerSupply Status State Voltage Current Identify --------------------------------------------------------------------------- pwrs0 OK on OK OK Off pwrs1 OK on OK OK Off Slot Status (V)Port Identify -------------------------------------------------- slot0 OK /c0/p0 Off slot1 NO-DEVICE - Off slot2 OK /c0/p1 Off slot3 OK /c0/p2 Off slot4 OK /c0/p3 Off slot5 OK /c0/p4 Off slot6 OK /c0/p5 Off slot7 OK /c0/p6 Off slot8 OK /c0/p7 Off slot9 OK /c0/p8 Off slot10 OK /c0/p9 Off slot11 NO-DEVICE - Off
This command shows the current setting of the given attribute(s). One or many attributes can be requested. An invalid attribute will terminate the loop. Possible attributes are: vendor, prodid, prodrev, firmware, controllers, slots, fans, temp and pwrs.
This command reports the product vendor of the specified enclosure.
Example:
//localhost> /c1/e0 show vendor /c1/e0 Vendor = LSI
This command reports the product ID of the specified enclosure.
Example:
//localhost> /c1/e0 show prodid /c1/e0 Product ID = DE1600-SAS
This command reports the product revision of the specified enclosure.
Example:
//localhost> /c1/e0 show prodrev /c1/e0 Product Revision = 0314
This command reports the SEP(s) and corresponding firmware version in the specified expander. Unlike other enclosure show commands, this is for the 9690SA and 9750 controllers with Release 10.2 or later only.
Example:
//localhost> /c1/e0 show firmware /c1/e0 SEP=0, Firmware Version = 90.00.03.14 /c1/e0 SEP=1, Firmware Version = 90.00.03.14
See also:
/cx/ex update fw=filename_with_path [sep=n] [force]
This command reports the controller that the specified enclosure is attached to. For the new syntax, this command is not very useful, since the controller that the enclosure is attached to is known and is part of the input command. This command was designed mainly for enclosures with the older syntax.
Example:
//localhost> /c0/e0 show controllers /c0/e0 connects to controller /c0
This command reports summary information of the slots within the specified enclosure. In the information table, the Slot column lists the slot IDs, the Status column lists the status of each slot, the (V)Port column shows the associated port or virtual port of each slot, and finally, the Identify column lists the Identify setting of the slots.
Example:
//localhost> /e0 show slots
Slot Status (V)Port Identify ---------------------------------------------------- slot0 OK /c0/p0 No slot1 OK /c0/p1 Yes slot2 NO-DEVICE - No slot3 NO-DEVICE - No
This command reports summary information of the fans within the specified enclosure. In the information table, the Fan column lists the fan IDs, the Status column lists the status of each fan, the State column shows if the fan is ON or OFF. The two columns related to fan speed shows the level and RPM (revolutions per minute), and finally, the Identify column lists the Identify setting of the fans.
Example:
//localhost> /c0/e0 show fans
---Speed---
Fan Status State Step RPM Identify
------------------------------------------------------------
fan0 OK ON 1 2670 Off
fan1 OK ON 1 9370 Off
fan2 OK ON 1 8540 Off
fan3 OK ON 1 2810 Off
fan4 OK ON 1 9240 Off
fan5 OK ON 1 8330 Off
This command reports summary information of the temperature sensors within the specified enclosure. In the information table, the TempSensor column lists the temperature sensor IDs, the Status column lists the status of each temperature sensor, the Temperature column shows the temperature at the sensors, and finally, the Identify column lists the Identify setting of the temperature sensors.
Example:
//localhost> /c0/e0 show temps
TempSensor Status Temperature Identify -------------------------------------------------------- temp0 OK 41C(105F) Off temp1 OK 37C(98F) Off temp2 OK 34C(93F) Off temp3 OK 38C(100F) Off temp4 OK 38C(100F) Off temp5 OK 34C(93F) Off temp6 NOT-INSTALLED - Off temp7 NOT-INSTALLED - Off
This command reports summary information of the power supplies within the specified enclosure. In the information table, the PowerSupply column lists the IDs of the power supply, the Status column lists the status of each power supply, the State column indicate if the unit is ON or OFF, the Voltage and Current columns indicate whether the voltage or current is under or over the required thresholds, and finally, the Identify column lists the Identify setting of the power supplies.
Example:
//localhost> /c0/e0 show pwrs PowerSupply Status State Voltage Current Identify --------------------------------------------------------------------------- pwrs0 OK on OK OK Off pwrs1 OK on OK OK Off
This command reports summary information of the alarms within the specified enclosure. In the information table, the Alarm column lists the alarm units' IDs, the Status column lists the status of each alarm, the State column indicates if the alarm unit is ON or OFF, and the Audibility column indicate whether the alarm is unmute or muted.
Example:
//localhost> /c0/e0 show alarms
Alarm Status State Audibility --------------------------------------------------- alm0 OK OFF UNMUTE
This command shows the current setting of all the enclosure attributes and the enclosure summary tables.
This command allows you to download a specified expander firmware image to the target SEP (Storage Enclosure Processor) expander that supports the SES-2 (SCSI Enclosure Services) standard for enclosure management. (CCU enclosures with SAF-TE protocol are not supported.)
This command is for the 9690SA and 9750 controllers with Release 10.2 or later only.
The fw=filename_with_path attribute allows you to specify the firmware image file name along with its path. Please note that filename_with_path could not have spaces (as Windows allows).
The firmware image specified by filename_with_path will be validated and examined for version difference. If the image is valid a subsequent message will indicate the detected version difference, along with a table showing the SEP number and the firmware versions. You are then asked with a prompt to continue. If you enter "y", the download process will initiate.
The sep=n attribute is optional. It identifies the target SEP expander in the system. Valid range is {0..9}. Without it being specified, the default which is 0 (zero), will be used.
The force attribute is optional. With it the warning message, version check, and prompt to proceed are all bypassed. The image will initiate the download immediately.
IMPORTANT! Please note the following regarding usage of this command.
1) The expander models that are supported with this command are indicated in a compatibility list for your reference. Only expander models in this list are supported. Please refer to: http://www.lsi.com/channel/support/marketing_resources/index.html. Click on the Data and Interoperability tab, and then click on the 3ware Interoperability Information link to check if your expander is supported.
2) Please make sure there is no I/O activity between the controller and the target expander during the download process. For example, be sure to unmount any mounted volumes, or stop any background tasks that may be running and do not start or schedule any background tasks such as rebuilds or verifies with the units or drives in the target expander during the time of download.
3) The expander requires reboot for the new firmware image to take effect.
Example:
//localhost> /c1/e0 update fw=c:\tmp\Badger_0314.esm
Warning: Updating firmware that is incompatible with your device can render the device unusable. Before you update the firmware, it is recommended that you:
1) Backup your data.
2) Verify with your enclosure vendor that you have the correct image.
3) Have a copy of the existing expander firmware image so that you can roll back, if necessary.
4) Make sure there is no I/O activity between the controller and the target expander (see instructions in user documentation).
Examining firmware image for download to /c1/e0 ... Done.
Download version is newer than current.
SEP New-Firmware Current-Firmware Vendor ---------------------------------------------------------------- 0 90.00.03.15 80.00.03.13 LSI
Given the above compatibility information ... Do you want to continue? Y|N [N]: y
Downloading the expander firmware from file [c:\tmp\Badger_0315.esm] ... Done. The new image will take effect after reboot.
In the output response to the command above, after
Examining firmware image for download to /c1/e0 ... Done.
A message is displayed regarding the version examination. In the example, it shows "Download version is newer than current." Depending on the examination, the message may be one of:
Download version is newer than current. Download version is older than current. Both versions are the same. Version not known.
If an error is detected in the examination, the message you will see may be one of:
Firmware image is not compatible with expander. Can not download firmware image, expander type unknown. Expander returned error to SES download microcode command. Enclosure firmware upgrade not supported by the controller; Try after upgrading controller firmware. Expander firmware image format not known.
See also:
/cx/ex show firmware
The slot commands provide information about the slot elements in the enclosure unit.
This command shows slot information on the specified enclosure /ex. The slot name is followed by its status. If a slot has been inserted with a drive and no fault has been detected, the status would indicate OK. If the slot is empty the status would indicate NO-DEVICE. The port that is correlated to the slot is indicated in the next column. If no device is found in that slot, this column would show a dash ('-'). The next column shows whether the specified slot has been identified.
Example:
//localhost> /c0/e0/slot1 show
Slot Status (V)Port Identify ---------------------------------------------------- slot1 OK /c0/p1 On
This command shows the identify status of the specified enclosure slot. If Identify = ON, the LED associated with the slot will blink. Likewise, for Identify = OFF, the LED associated will stop blinking or would not blink. If the enclosure does not support Slot Identify, this command will respond with 'N/A'.
Example:
//localhost> /c0/e0/slot1 show identify /c0/e0/slot1 Identify status = on
This command identifies the specified slot by setting the identify attribute to either ON or OFF, if there is an LED associated and if the enclosure supports Slot Identify. If supported, setting it to ON will blink the LED of the specified drive slot. For example:
//localhost> /c0/e0/slot1 set identify=on Setting Slot Identify on /c0/e0/slot1 to [on] ... Done.
These commands provide information about the fans in the enclosure unit.
This command shows information about the specified enclosure fan.
Example:
//localhost> /c0/e0/fan0 show
---Speed---
Fan Status State Step RPM Identify
------------------------------------------------------------
fan0 OK ON 1 2700 Off
This command shows the identify status of the specified enclosure fan. If Identify = ON, the LED associated with the fan will blink. Likewise, for Identify = OFF, the LED associated will stop blinking or would not blink. If the enclosure does not support Fan Identify, this command will respond with 'N/A'.
Example:
//localhost> /c0/e0/fan0 show identify /c0/e0/fan0 Identify status = off
This command identifies the specified enclosure fan by setting the identify attribute to either on or off, if there is an LED associated and if the enclosure supports Fan Identify. If supported, setting it to ON will blink the LED associated with the specified fan element.
Example:
//localhost> /c0/e0/fan1 set identify=on Setting Fan Identify on /c0/e0/fan1 to [on] ... Done.
This command sets the speed level of the specified enclosure fan. The speed level is a number in the range of <0..7>, where:
0 - Off 1 - Lowest 2 - Low 3 - Medium-low 4 - Medium 5 - Medium-high 6 - High 7 - Highest
Example:
//localhost> /c0/e0/fan1 set speed=1 Setting Fan Speed on /c0/e0/fan1 to [1] ... Done.
These commands provide information about the temperature sensors in the enclosure unit.
This command shows information about the specified enclosure temperature sensor. The possible status values are OK, OVER-WARNING, OVER-FAIL, UNDER-WARNING, UNDER-FAIL, where OVER denotes over-temperature and UNDER denotes under-temperature.
Example:
//localhost> /c0/e0/temp0 show
TempSensor Status Temperature Identify -------------------------------------------------------- temp0 OK 42C(107F) Off
This command shows the identify status of the specified enclosure temperature sensor. If Identify = ON, the LED associated with the temperature sensor will blink. Likewise, for Identify = OFF, the LED associated will stop blinking or would not blink. If the enclosure does not support Temperature Sensor Identify, this command will respond with 'N/A'.
Example:
//localhost> /c0/e0/temp0 show identify /c0/e0/temp0 Identify status = off
This command identifies the specified enclosure temperature sensor by setting the identify attribute to either ON or OFF, if there is an LED associated and if the enclosure supports Temperature Sensor Identify. If supported, setting it to ON will blink the LED associated with the specified temperature element.
Example:
//localhost> /c0/e0/temp1 set identify=on Setting Temperature Sensor Identify on /c0/e0/temp1 to [on] ... Done.
These commands provide information about the enclosure power supplies in the enclosure unit.
This command shows information about the specified enclosure power supply. The possible status values are OK, FAIL, NOT-INSTALLED, and OFF. The voltage and current columns indicate the threshold voltage and current status. The possible values for Voltage are OK, OVER-VOLTAGE, and UNDER-VOLTAGE. The possible values for Current are OK and OVER-CURRENT. In either case, OVER- means over the set threshold of the voltage or current.
Example:
//localhost> /c0/e0/pwrs0 show
PowerSupply Status State Voltage Current Identify --------------------------------------------------------------------------- pwrs0 OK on OK OK Off
This command shows the identify status of the specified enclosure power supply. If Identify = ON, the LED associated with the fan will blink. Likewise, for Identify = OFF, the LED associated will stop blinking or would not blink. If the enclosure does not support Power Supply Identify, this command will respond with 'N/A'.
Example:
//localhost> /c0/e0/pwrs0 show identify /c0/e0/pwrs0 Identify status = off
This command identifies the specified enclosure power supply by setting the identify attribute to either ON or OFF, if there is an LED associated and if the enclosure supports Power Supply Identify. If supported, setting it to ON will blink the LED associated with the specified power supply.
Example:
//localhost> /c0/e0/pwrs1 set identify=on Setting Power Supply Identify on /c0/e0/pwrs1 to [on] ... Done.
These commands provide information about the enclosure alarms in the enclosure unit.
This command shows information about the specified enclosure alarm. The possible status values are OK, FAIL, NOT-INSTALLED, and ACTIVATED. The status values are described below. The possible values for State are ON and OFF. The possible values for Audibility are UNMUTE and MUTE.
Possible Status values:
OK - Alarm device is functional and operational. FAIL - Alarm device has malfunctioned and is not operational. NOT-INSTALLED - Alarm device has not been installed. ACTIVATED - Alarm device is functional, and an error condition has been detected. This is a visual indication for the alarm, in the event that it may be muted.
Example:
//localhost> /c0/e0/alm0 show
Alarm Status State Audibility --------------------------------------------------- alm0 OK OFF UNMUTE
This command controls the audibility and state of the enclosure alarm. It provides the ability to silence the alarm after it has been turned on. It also gives you the option to mute or unmute the alarm setting. In the case where a known condition would set off the alarm and you do not wish to hear the sound of the alarm, this command could be used to mute the potential audible alarm.
Note: Some enclosures support alarms but not the mute/unmute function. For these enclosures, the command to set the alarm to mute will return an error message indicating that the feature is not supported. In this case, the alarm setting of unmute would seem to be supported. This is because the unmute setting is the default and as such there is no error response. In effect, for these enclosures, the alarm is not mutable and would stay unmute . Example:
//localhost> /c0/e0/alm0 set alarm=unmute Setting alarm audibility setting of /c0/e0/alm0 to [unmute] ... Done.
Note: You cannot turn ON the alarm. The alarm is turned on by firmware when it detects a degraded state pertaining to a drive or array. Setting the alarm to ON will return an error.
If an error condition or degraded state has been detected, the enclosure alarm or buzzer would be audible. To silence the alarm you may set the state of the alarm to OFF. You could also mute the alarm. The difference between using either is the following:
State or Audibility Persistence across reboot ------------------- ------------------------- ON/OFF Yes MUTE/UNMUTE No
For OFF, after you reboot, the alarm will sound as long as the system is still in a degraded state (i.e., the alarm is persistent across reboot).
For MUTE, after you reboot, the alarm will no longer sound even though the system is still in a degraded state (i.e., the alarm would not appear persistent across reboot).
For enclosures that do not support MUTE, there is no difference between OFF and MUTE.
The default values are UNMUTE and OFF.
The set of Help Command provides brief online help. Online help provides command syntax information, while detail about the command is deferred to the manpage. Just as the command set have implicit leveling that starts with the Shell object, online help also follows this leveling structure.
At top level of online help shows the set of objects that Help provides, these includes the shell object, and controller and enclosure objects:
//localhost> help
Copyright (c) 2010 LSI LSI/3ware CLI (version 2.00.11.014)
Commands Description ------------------------------------------------------------------- show Displays information about controller(s), unit(s) and port(s). flush Flush write cache data to units in the system. rescan Rescan all empty ports for new unit(s) and disk(s). update Update controller firmware from an image file. commit Commit dirty DCB to storage on controller(s). (Windows only) /cx Controller specific commands. /cx/ux Unit specific commands. /cx/px Port specific commands. /cx/phyx Phy specific commands. /cx/bbu BBU specific commands. (9000 series) /cx/ex Enclosure specific commands. (9690SA, 9750) /ex Enclosure specific commands. (9550SX, 9650SE)
Certain commands are qualified with constraints of controller type/model support. Please consult the tw_cli documentation for explanation of the controller-qualifiers.
Type help <command> to get more details about a particular command. For more detail information see tw_cli's documentation.
Please note that the version of CLI is indicated at the top of the output.
As indicated, help<command> would give more information about the command or, display all possible sub-commands associated with the specified object. For example, for Help on the controller object /cx:
//localhost> help /cx
/cx show
/cx show Attribute [Attribute ...] where Attribute is:
allunitstatus|bios|firmware|driver|drivestatus|exportjbod|
autocarve(9550SX and higher)|autorebuild(9550SX and higher)|
carvesize(9550SX and higher)|memory|model|serial|monitor|
ctlbus(9550SX and higher)|pcb|achip|pchip|numdrives|numports|
numunits|unitstatus|ondegrade(9500S only)|spinup|stagger
/cx show all where all means Attributes and configurations.
/cx show diag
/cx show alarms [reverse]
/cx show events [reverse]
/cx show AENs [reverse]
/cx show rebuild (9000 series)
/cx show rebuildrate
/cx show rebuildmode (see note 3)
/cx show verify (9000 series)
/cx show verifyrate
/cx show verifymode (see note 3)
/cx show selftest (9000 series)
/cx show phy (see note 4)
/cx show dpmstat [type=<inst|ra|ext>]
(9550SX and higher for type=inst and type=ra;
9650SE and higher for type=ext)
/cx add type=<RaidType> disk=<p:p|p-p|p:p-p> (where p = port or drive number)
[stripe=<size>] [nocache|nowrcache] [nordcache|rdcachebasic] (see note)
[name=string (9000 series)] [ignoreECC] [autoverify|noautoverify]
[v0=n|vol=a:b:c:d] (n,a,b,c,d = size of volume in GB) (9000 series)
[noqpolicy] [storsave=<protect|balance|perform>] (9550SX and higher)
[noscan] [rapidrecovery=<all|rebuild|disable>] (9650SE and higher)
[group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>]
(group=13-16 9690SA and higher)
RaidType = { raid0, raid1, raid5, raid10, raid50, single,
spare, raid6 (9650SE and higher) }
/cx add rebuild=ddd:hh:duration (9000 series)
/cx add verify=ddd:hh:duration (9000 series)
/cx add selftest=ddd:hh (9000 series)
/cx del rebuild=slot_id (9000 series) /cx del verify=slot_id (9000 series) /cx del selftest=slot_id (9000 series)
/cx set ondegrade=cacheoff|follow (9500S only)
/cx set spinup=nn (9000 series)
/cx set stagger=nn (9000 series)
/cx set autocarve=on|off (9550SX and higher)
/cx set carvesize=[1024..32768] (9550SX and higher)
/cx set rebuild=enable|disable|<1..5> (enable|disable for 9000 series)
/cx set rebuildrate=<1..5>
/cx set rebuildmode=<adaptive|lowlatency> (see note 3)
/cx set verify=enable|disable|<1..5> (enable|disable for 9000 series)
/cx set verify=advanced|basic|<1..5> (9650SE and higher)
/cx set verifyrate=<1..5>
/cx set verifymode=<adaptive|lowlatency> (see note 3)
/cx set selftest=enable|disable (9000 series)
/cx set autorebuild=on|off (9550SX and higher)
/cx set autodetect=on|off disk=<p:-p>|all (9000 series)
/cx set dpmstat=on|off (9550SX and higher)
/cx set verify=basic [pref=ddd:hh] where hh= {00..23} and
ddd = {mon|tue|wed|thu|fri|sat|sun} (9650SE and higher)
/cx update fw=filename_with_path [force] (9000 series) /cx flush /cx commit (Windows only) (Also known as shutdown) /cx start mediascan (7000/8000 only) /cx stop mediascan (7000/8000 only) /cx rescan [noscan] NOTE: Does not import non-JBOD on 7000/8000 models.
Note:
(1) 'nowrcache' and 'nocache' disable the write cache and they behave
identically.
(2) 'nordcache' is an override to the read cache default; use to
disable the read cache. For Read Cache Basic use rdcachebasic.
Read Cache is supported in the 9650SE or newer controllers with
Release 9.5.2 or later.
(3) 'rebuildmode' and 'verifymode' are supported in the 9650SE or newer
controllers with Release 9.5.2 or later.
(4) '/cx show phy' is supported in the 9650SE or newer controllers
with Release 9.5.2 or later.
For Help on the next level, i.e., for the commands show, add, del, set, update, flush, commit, etc, use for example, help /cx add to see the syntax of the add commands associated with /cx:
//localhost> help /cx add
/cx add type=<RaidType> disk=<p:p|p-p|p:p-p> (where p = port or drive number)
[stripe=<size>] [nocache|nowrcache] [nordcache|rdcachebasic] (see note)
[name=string (9000 series)] [ignoreECC] [autoverify|noautoverify]
[v0=n|vol=a:b:c:d] (n,a,b,c,d = size of volume in GB) (9000 series)
[noqpolicy] [storsave=<protect|balance|perform>] (9550SX and higher)
[noscan] [rapidrecovery=<all|rebuild|disable>] (9650SE and higher)
[group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>]
(group=13-16 9690SA and higher)
RaidType = { raid0, raid1, raid5, raid10, raid50, single,
spare, raid6 (9650SE and higher) }
/cx add rebuild=ddd:hh:duration (9000 series)
/cx add verify=ddd:hh:duration (9000 series)
/cx add selftest=ddd:hh (9000 series)
Note:
(1) 'nowrcache' and 'nocache' disable the write cache and they behave
identically.
(2) 'nordcache' is an override to the read cache default; use to
disable the read cache. For Read Cache Basic use rdcachebasic.
Read Cache is supported in the 9650SE or newer controllers with
Release 9.5.2 or later.
(3) 'rebuildmode' and 'verifymode' are supported in the 9650SE or newer
controllers with Release 9.5.2 or later.
(4) '/cx show phy' is supported in the 9650SE or newer controllers
with Release 9.5.2 or later.
Note: Help stops at this /Object/Command level. Help does not extend to the Attribute level, and thus inquiry for /Object/Command/Attribute is not valid. For example, 'help /cx add verify' is not a valid Help command string and the system would respond with a list of all '/cx add' commands followed by an error message.
An alternate way to use Help is with '?' or 'help' at the end of a command string. That is, starting with the object, followed by the command, followed by '?' or 'help'. For example, '/c0' being our object and 'show' is our command:
//localhost> /c0 show ?
/cx show
/cx show Attribute [Attribute ...] where Attribute is:
allunitstatus|bios|firmware|driver|drivestatus|exportjbod|
autocarve(9550SX and higher)|autorebuild(9550SX and higher)|
carvesize(9550SX and higher)|memory|model|serial|monitor|
ctlbus(9550SX and higher)|pcb|achip|pchip|numdrives|numports|
numunits|unitstatus|ondegrade(9500S only)|spinup|stagger
/cx show all where all means Attributes and configurations.
/cx show diag
/cx show alarms [reverse]
/cx show events [reverse]
/cx show AENs [reverse]
/cx show rebuild (9000 series)
/cx show rebuildrate
/cx show rebuildmode (see note 3)
/cx show verify (9000 series)
/cx show verifyrate
/cx show verifymode (see note 3)
/cx show selftest (9000 series)
/cx show phy (see note 4)
/cx show dpmstat [type=<inst|ra|ext>]
(9550SX and higher for type=inst and type=ra;
9650SE and higher for type=ext)
Note:
(1) 'nowrcache' and 'nocache' disable the write cache and they behave
identically.
(2) 'nordcache' is an override to the read cache default; use to
disable the read cache. For Read Cache Basic use rdcachebasic.
Read Cache is supported in the 9650SE or newer controllers with
Release 9.5.2 or later.
(3) 'rebuildmode' and 'verifymode' are supported in the 9650SE or newer
controllers with Release 9.5.2 or later.
(4) '/cx show phy' is supported in the 9650SE or newer controllers
with Release 9.5.2 or later.
Note: Again, Help stops at the command keyword level, so that '/c0 show selftest help' or '/c0 show phy ?' would respond with an output identical to /c0 show phy followed by /c0 show ?. In this case no error follows. Please also note that if /c0 is not a valid controller in your system, an error is generated and this way of using help would not work. Instead you will get the following:
//localhost> /c4 show ? Error: (CLI:003) Specified controller does not exist.
The following lists the Help Commands, with a brief description for each command.
This command provide a table of contents, providing an overall navigational help. Typical output looks like:
//localhost> help
Copyright (c) 2010 LSI LSI/3ware CLI (version 2.00.11.014)
Commands Description ------------------------------------------------------------------- show Displays information about controller(s), unit(s) and port(s). flush Flush write cache data to units in the system. rescan Rescan all empty ports for new unit(s) and disk(s). update Update controller firmware from an image file. commit Commit dirty DCB to storage on controller(s). (Windows only) /cx Controller specific commands. /cx/ux Unit specific commands. /cx/px Port specific commands. /cx/phyx Phy specific commands. /cx/bbu BBU specific commands. (9000 series) /cx/ex Enclosure specific commands. (9690SA, 9750) /ex Enclosure specific commands. (9550SX, 9650SE)
Certain commands are qualified with constraints of controller type/model support. Please consult the tw_cli documentation for explanation of the controller-qualifiers.
Type help <command> to get more details about a particular command. For more detail information see tw_cli's documentation.
This command provides specific show related help, illustrating various ways to use the show command. It provides reports on Controllers, Units and Drives. See the Shell Object Messages section for more on show.
This command provides specific flush related help, illustrating various ways to use the flush command. See the Shell Object Messages section for more.
This command provides specific rescan related help, illustrating various ways to use the rescan command. See the Shell Object Messages section for more.
This command provides specific update related help. See the Shell Object Messages section for more.
This command provides specific commit related help, illustrating various ways to use the commit command. See the Shell Object Messages section for more.
This command provides specific focus related help, illustrating various ways to use the focus command. See the Shell Object Messages section for more.
This command provides specific controller /cx related help, illustrating various commands associated with the controller /cx. See the Controller Object Messages section for more.
This command provides specific unit /cx/ux related help, illustrating various commands to use on a unit /cx/ux. See the Controller Object Messages section for more.
This command provides specific /cx/px related help, illustrating various ways to use the /cx/px command. See the Port Object Messages section for more.
This command provides specific /cx/phyx related help, illustrating various ways to use the /cx/phyx command. See the Phy Object Messages section for more.
This command provides specific /cx/bbu related help, illustrating various ways to use the /cx/bbu command. See the BBU Object Messages section for more.
This command provides specific enclosure /cx/ex related help, illustrating various commands associated with the enclosure /cx/ex. See the Enclosure Services Commands section for more.
This command provides specific slot /cx/ex/slotx related help, illustrating various ways to use the /cx/ex/slotx command. See the Enclosure Element Slot section for more.
This command provides specific fan /cx/ex/fanx related help, illustrating various ways to use the /cx/ex/fanx command. See the Enclosure Element Fan section for more.
This command provides specific temperature sensor /cx/ex/tempx related help, illustrating various ways to use the /cx/ex/tempx command. See the Enclosure Element Temperature Sensor section for more.
This command provides specific power supply /cx/ex/pwrsx related help, illustrating various ways to use the /cx/ex/pwrsx command. See the Enclosure Element Power Supply section for more.
CLI has a logging function that makes an entry into a log file for each command line that makes a change to the controller configuration (for example, add/delete units). Both CLI and 3DM2 has this logging function and it is enabled by default.
Setting the environment variable to ON or OFF will enable or disable the logging function, respectively. The environment variable is TW_CLI_LOG, and the method for setting it depends on the operating system.
The sections and examples below show the log command syntax and the log file location depending on the operating system. Note where ON is indicated, OFF may be substituted.
For Linux, FreeBSD, Mac OS, and OpenSolaris, the command depends on the type of shell:
If bash, ksh, or sh, use "export TW_CLI_LOG=ON"
If csh, use "setenv TW_CLI_LOG ON"
Note: The shell that you are running CLI must be the same shell that you input the command to set the environment variable.
For Windows, set the environment variable by clicking on the start button and then right-clicking on My Computer and selecting Properties. In Properties, click on the Advanced tab. Then click on the Environment Variables button. If you don't see TW_CLI_LOG you may add and set it to ON of OFF by clicking on New, (or edit an existing one by clicking on Edit).
Since the default of Command Logging is ON, if you wish the turn it off, you could set the environment variable TW_CLI_LOG to OFF.
When you cycle power your system, the new environment variable is recorded by Windows and read by CLI upon system startup, after which CLI will stop logging any new commands associated with the controller.
For Linux, FreeBSD, Mac OS, and OpenSolaris, the log file is in the /var/log directory.
For Windows Vista and Windows Server 2008, the log file is stored in
\ProgramData\3ware
Note that ProgramData is a hidden folder by default. To display it in Windows Explorer, enter c:\ProgramData in the location field at the top of the Explorer Window. To make the folder permanently visible, select Organize->Folder and Search Options from the Explorer menu, choose the View tab, and select the Show hidden files and folders option in Advance settings.
For previous versions of Windows (XP, Server 2003, etc), the log file is stored in
\Documents and Settings\All Users\Application Data\3ware
This section lists some of the features that CLI supports for the 3ware RAID product. While many system features require a few commands, some require or involve a set of commands that work together. Also, some of these features may be compenhensively more complex to described in a few discreet commands. The purpose of this section is to provide an encapsulated view of selected system features with their command set.
Please note that you could consult the 3ware SAS/SATA RAID Software User Guide for more in-depth conceptual information about features that can be used to control your 3ware RAID controller as well.
The subsections which follow contain descriptions, the commands applicable, and related information such as setup and operation details of a feature and its function. The following is a list of the subsections:
The commands within the subsections below also appear in the Primary Command Syntax section of this document. While some commands contain similar or identical information or examples, others may not. Those that do not is likely due to context, legacy, or other factors. In any case, the explanations are consistent across the two sections in this document.
Performance monitoring and statistics of the RAID controller, as a basis for analysis of performance, may also provide information for qualification and diagnostics. The Drive Performance Monitor of CLI supports statistics of queue depths, IOPs, transfer rate, response time for reads/writes, and command reads/writes.
Queue depth refers to the number of reads/writes currently outstanding, IOPs refers to the number of reads/writes completing, transfer rate refers to the number of sectors read/written, response time refers to the execution time of all commands, and command read/writes refers to the drive and drive sectors' accumlated read and write commands.
The types of drive performance statistics supported are organized into five groups:
- instantaneous - running average - long command times - response histogram - extended drive statistics
The instantaneous measurements provide a short duration average. The running average is a measure of long-term averages that smooth out the data, and results in older results fading from the average over time. The long command times is a collection of the commands with the longest read/write response time. The response histogram categorizes the read/write execution times and group them together based on time frames. Finally, the extended drive statistics refers to statistics of a drive's read commands, write commands, write commands with FUA (Force Unit Access), flush commands, and a drive sectors's read, write, and write commands with FUA.
Note: This feature is for the 9550SX and higher model controllers, with exception of the commands related to extended drive statistics, that are supported on the 9650SE, 9690SA and 9750 controllers only.
OPERATION
The command syntax falls into three categories: 1) Configuration, 2) port-based drive statistics, and 3) controller-based drive statistics summary. The configuration category allows the user to see the settings as well as change them. At this time, the only setting that the user can change is 'enable' or 'disable' of the Drive Performance Monitor. The port-based 'show' commands provide requested statistics based on type. The port-based 'set' command clears the specified type statistics. While these commands require the specification of the port each time, the controller-based commands do not and provide the information in a summary format.
Note: Please note that the keyword 'pmstat' and 'dpmstat' generate the same system response. At this time both could be used for Drive Performance Monitor statistics. In the future if other types of performance monitor support would be added, 'pmstat' would denote Performance Monitor while 'dpmstat' would refer to Drive performance statistics only.
The following table summarizes the drive performance monitor commands. The command type, command syntax, and corresponding descriptions are listed. Following the table is an important note, which is then followed by examples and usage of the commands.
--------------+-----------------------------------+-----------------------------------
COMMAND TYPE | COMMAND SYNTAX | DESCRIPTION
--------------+-----------------------------------+-----------------------------------
Configuration | /cx show dpmstat | Show configuration and setting.
| | See example below. Display
| | will also show default set of
| | drive statistics (i.e., type=inst).
+-----------------------------------+-----------------------------------
| /cx set dpmstat=on | Enable or disable performance
| /cx set dpmstat=off | monitoring. See note below.
--------------+-----------------------------------+-----------------------------------
Port-based | /cx/px show dpmstat type=inst | Request for drive statistics on
Statistics | /cx/px show dpmstat type=ra | specified port. inst=instantaneous,
| /cx/px show dpmstat type=lct | ra=running average, lct=long cmd
| /cx/px show dpmstat type=histdata | times, histdata=histogram data,
| /cx/px show dpmstat type=ext | and ext=extended drive statistics.
+-----------------------------------+-----------------------------------
| /cx/px set dpmstat=clear | Clear statistics counters. If
| /cx/px set dpmstat=clear type=ra | type=ra, both Running Avg and
| /cx/px set dpmstat=clear type=lct | Histogram Data will be cleared.
| /cx/px set dpmstat=clear type=ext | If type=lct, only the Long Cmd
| | Times data will be cleared. If
| | type=ext, the extended drive
| | statistics are cleared. If no
| | type is specified, the default
| | is type=ra.
--------------+-----------------------------------+-----------------------------------
Controller- | /cx show dpmstat | Request for drive statistics sum-
based | /cx show dpmstat type=inst | mary of the specified controller.
Statistics | /cx show dpmstat type=ra | inst=instantaneous, ra=running
| /cx show dpmstat type=ext | average, ext=extended drive
| | statistics. The default is
| | Instantaneous.
--------------+-----------------------------------+-----------------------------------
Note: The command '/cx show dpmstat' shows the performance monitor configuration and the default set of summary statistics (type=inst) shows data regardless of whether the performance monitor setting is ON or OFF. If the setting is ON and I/O is running, the statistics data will change over time because the measurements are being averaged. If the setting is OFF, the same table layout is shown. However, since no calculations are taking place, the data will be static and remains unchanged. Thus, when the drive performance monitor is OFF, the data shown may not be zeros.
Examples of the command's usage are shown below.
To display the configuration of the Drive Performance Monitor of the specified controller (default statistics display is instantaneous data), use command /cx show dpmstat. For example:
//localhost> /c0 show dpmstat Drive Performance Monitor Configuration for /c0 ... Performance Monitor: ON Version: 1 Max commands for averaging: 100 Max latency commands to save: 10 Requested data: Instantaneous Drive Statistics
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
------------------------------------------------------------------------
p0 NOT-PRESENT - - - - -
p1 NOT-PRESENT - - - - -
p2 OK - - - - -
p3 OK u0 10 93 2.907 85
p4 OK u1 10 84 2.640 95
p5 OK - - - - -
p6 NOT-PRESENT - - - - -
p7 NOT-PRESENT - - - - -
In the configuration information above, 'Version' refers to the firmware version of the Performance Monitor, 'Max commands for averaging' refers to the maximum number of commands that can be saved and used for calculating the average, and 'Max latency commands to save' refers to the maximum number of commands with high latency that are saved. The number of elements in the buffer is determined by these configurations and the memory constraints of the system.
To set the Drive Performance Monitor to 'enable' or 'disable', use commands /cx set dpmstat=on and /cx set dpmstat=off, respectively. For example:
//localhost> /c0 set dpmstat=off Setting Drive Performance Monitoring on /c0 to [off]... Done.
To display the running average statistics data at the controller level, i.e., as a summary of the running average data for the set of drives attached to the controller, use command /cx show dpmstat type=ra. For example:
//localhost> /c0 show dpmstat type=ra Drive Performance Monitor Configuration for /c0 ... Performance Monitor: OFF Version: 1 Max commands for averaging: 100 Max latency commands to save: 10 Requested data: Running Average Drive Statistics
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
------------------------------------------------------------------------
p0 NOT-PRESENT - - - - -
p1 NOT-PRESENT - - - - -
p2 OK - - - - -
p3 OK u0 0 435 25.249 2
p4 OK u1 0 366 21.630 3
p5 OK - - - - -
p6 NOT-PRESENT - - - - -
p7 NOT-PRESENT - - - - -
To display the running average drive statistics of the specified port, use command /cx/px show dpmstat type=ra. For example:
//localhost> /c0/p3 show dpmstat type=ra
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
---------------------------------------------------------------------
p3 OK u0 0 435 25.249 2
For data associated with commands that have long command times for the specified port, use command /cx/px show dpmstat type=lct. For example:
//localhost> /c0/p3 show dpmstat type=lct
Port Status Unit ------------------------------ p3 OK u0
Resp
Date Time Time(ms) --------- CDB / ATA Task File (hex) -----------
------------------------------------------------------------------------------
2007-02-09 13:47:57 383.216 00 80 60 40 92 9f 8a 40 1a 00 00 00 00 00 00 00
2007-02-09 13:47:57 390.809 00 80 60 40 13 eb 30 40 26 00 00 00 00 00 00 00
2007-02-09 13:47:57 405.478 00 80 60 40 61 11 20 40 26 00 00 00 00 00 00 00
2007-02-09 13:47:57 410.379 00 80 60 40 cd 8b b9 40 23 00 00 00 00 00 00 00
2007-02-09 13:47:57 419.002 00 80 60 40 5e df d1 40 29 00 00 00 00 00 00 00
2007-02-09 13:47:57 444.250 00 80 60 40 8b c0 36 40 2e 00 00 00 00 00 00 00
2007-02-09 13:47:57 527.994 00 80 60 40 6e a5 b6 40 03 00 00 00 00 00 00 00
2007-02-09 13:47:57 569.429 00 80 60 40 3b e2 02 40 2d 00 00 00 00 00 00 00
2007-02-09 13:47:57 609.526 00 80 60 40 27 1c e9 40 2b 00 00 00 00 00 00 00
2007-02-09 13:47:57 612.051 00 80 60 40 dd 0b d1 40 2c 00 00 00 00 00 00 00
Note that in addition to the time and date stamps of the commands with the long response times, their corresponding CDB or ATA Task File is displayed.
For histogram of IOPs grouped together based on response time associated with the specified port, use command /cx/px show dpmstat type=histdata. For example:
//localhost> /c0/p3 show dpmstat type=histdata
Port Status Unit ------------------------------ p3 OK u0
Bin Response Time(ms) IO Count ----------------------------------------------- 1 1 0 2 2 0 3 3 0 4 4 0 5 5 0 6 6 0 7 7 0 8 8 0 9 9 0 10 10 0 11 20 204 12 30 190 13 40 161 14 50 136 15 60 130 16 70 112 17 80 94 18 90 80 19 100 540 20 200 95 21 300 42 22 400 11 23 500 2 24 600 2 25 700 0 26 800 0 27 900 0 28 1000 0 29 2000 0 30 3000 0 31 4000 0 32 5000 0 33 6000 0 34 7000 0 35 8000 0 36 9000 0 37 10000 0 38 10000+ 0
Note that there is a set of 38 'Bins' and each bin denotes a Response Time category. The number of I/Os or commands that fall into the Response Time time range of the designated bin would fall into that bin. In the display above, there are no commands with response times of 10 milliseconds or shorter, and there are 204 commands with 20 milliseconds. Note that for the I/O application and activities to this drive, the concentration of the longer response times is toward the middle, as in a statistical Normal Curve.
To clear the running average statistics data of the specified port, use command /cx/px set dpmstat=clear type=ra. For example:
//localhost> /c0/p3 set dpmstat=clear type=ra Clearing Port Performance Monitor running average statistics on /c0/p3... Done.
Please note that this clears the Running Average and Histogram data.
Note: Usage of the 'clear' command without specifying 'type' implies the default, which is 'type=ra'. The default thus effectively clears both the running average statistics and histogram data. Also, some statistics data types cannot be cleared, such as setting 'type=inst' or 'type=histdata'. Attempting to clear these will return an error.
If I/O traffic to the drive has been stopped, after clearing, a subsequent request to show the running average statistics would show, for example:
//localhost> /c0/p3 show dpmstat type=ra
Queue Xfer Resp
Port Status Unit Depth IOPs Rate(MB/s) Time(ms)
---------------------------------------------------------------------
p3 OK u0 0 0 0.000 0
Note that IOPs, Xfer Rate (transfer rate), and Resp Time (response time) are all zeros.
If I/O traffic to the drive has been stopped, after clearing, a subsequent request to show the histogram data would show, for example:
//localhost> /c0/p3 show dpmstat type=histdata
Port Status Unit ------------------------------ p3 OK u0
Bin Response Time(ms) IO Count
-----------------------------------------------
1 1 0
2 2 0
3 3 0
4 4 0
5 5 0
6 6 0
7 7 0
8 8 0
9 9 0
10 10 0
11 20 0
12 30 0
13 40 0
14 50 0
15 60 0
16 70 0
17 80 0
18 90 0
19 100 0
20 200 0
21 300 0
:
:
:
To display the extended drive statistics associated with the specified port, use command /cx/px show dpmstat type=ext. For example:
//localhost> /c3/p0 show dpmstat type=ext Requested data: Extended Drive Statistics
Sectors Commands
----------------------------- ---------------------------------------
Port Read Write Write-FUA Read Write Write-FUA Flush
------------------------------------------------------------------------------
p0 28704384 0 28704384 28704448 0 0 0
To display the extended drive statistics associated with the specified controller, as a summary of the drives, use command /cx show dpmstat type=ext. For example:
//localhost> /c3 show dpmstat type=ext Extended Drive Statistics for /c3 ...
Sectors Commands
----------------------------- ---------------------------------------
Port Read Write Write-FUA Read Write Write-FUA Flush
------------------------------------------------------------------------------
p0 28704384 0 28704384 28704448 0 0 0
p2 28704384 28704448 0 0 0 0 0
p3 28704704 0 0 0 0 0 0
p6 0 0 0 0 0 0 0
While the data fields are large and sufficient for a 32-bit number, depending on the amount of I/O and the rate or duration of the data transfer, overflow may take place. In this scenario, the data fields that contains the overflow is marked with '########', as in the following example:
//localhost> /c3 show dpmstat type=ext Extended Drive Statistics for /c3 ...
Sectors Commands
----------------------------- ---------------------------------------
Port Read Write Write-FUA Read Write Write-FUA Flush
------------------------------------------------------------------------------
p0 ######## 0 158838656 158838720 0 0 0
p2 ######## ######## ######## ######## ######## ######## ########
p3 ######## 0 0 0 0 0 0
p6 0 0 0 0 0 0 0
The clear command can be used to zero out the counters. To clear the extended drive statistics associated with the specified port, we use the command /cx/px set dpmstat=clear type=ext. For example:
//localhost> /c3/p0 set dpmstat=clear type=ext Clearing Performance Monitor extended drive statistics on /c3/p0 ... Done.
Rapid RAID Recovery can speed up the rebuild, initialize, and verify processes and tasks in response to an unclean system shutdown. Effectively this feature provides for expedited boot-up time.
This feature is supported on the 9750, 9690SA and 9650SE (with supporting firmware) controllers. Also, it is only supported on redundant arrays only, such as RAID-1, RAID-5, RAID-6, RAID-10 and RAID-50. This feature is not supported over migration.
OPERATION
The usage of this feature consists of a set of commands that sets the feature to one of three possible states. This configuration may be defined at unit creation time or after a unit has been created. Below is a summary of the commands for this feature.
/cx add ... rapidrecovery=all|rebuild|disable /cx/ux set rapidrecovery=all|rebuild|disable [quiet] /cx/ux show rapidrecovery
If you set this option to all, upon an unclean system shutdown, the Rapid RAID Recovery policy will apply to rebuild, initialize, and verify tasks at reboot. If you set this option to rebuild, then only the rebuild task will be applied. If you set it to disable, then none of the tasks will be sped up. Please note that once this attribute is set for the unit, the policy setting is persistent in the system until it is disabled.
Note: Once the Rapid RAID Recovery has been "disabled" for a unit, it cannot be changed again for that unit. As a result, if you issue the '/cx/px set rapidrecovery=disable' command, a message along with a prompt for input to proceed will appear. To turn off the message and prompt for scripting purposes, use the quiet option.
Note: The default setting of Rapid RAID Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled.
Consider a 9690SA controller with four drives attached. Creating a RAID-5 unit with the rapidrecovery attribute set to the all option:
//localhost> /c1 add type=raid5 disk=0:2:3 rapidrecovery=all
Creating new unit on controller /c1 ... Done. The new unit is /c1/u0. Setting AutoVerify=ON for the new unit ... Done. Setting Rapid RAID Recovery policy on /c1/u0 to [all] ... Done. Setting default Command Queuing Policy for unit /c1/u0 to [on] ... Done. Setting write cache=ON for the new unit ... Done. Warning: You do not have a battery backup unit for /c1/u0 and the enabled write cache (default) may cause data loss in the event of power failure.
Subsequent inquiry of the controller and unit information would show:
//localhost> /c1 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 298.002 ON ON
VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1 p2 OK u0 149.05 GB SATA 2 - WDC WD1600JS-22NCB1 p3 OK u0 149.05 GB SATA 3 - WDC WD1600JS-22NCB1 p6 OK - 34.18 GB SAS 6 - SEAGATE ST936701SS
//localhost> /c1/u0 show
Unit UnitType Status %RCmpl %V/I/M VPort Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-5 OK - - - 64K 298.002 u0-0 DISK OK - - p0 - 149.001 u0-1 DISK OK - - p2 - 149.001 u0-2 DISK OK - - p3 - 149.001 u0/v0 Volume - - - - - 298.002
The created RAID-5 unit would be configured with Rapid RAID Recovery set to "all" that the user could see with the 'show" command:
//localhost> /c1/u0 show rapidrecovery /c1/u0 Rapid RAID Recovery policy setting = all
To change the Rapid RAID Recovery setting to 'rebuild':
//localhost> /c1/u0 set rapidrecovery=rebuild Setting Rapid RAID Recovery policy on /c1/u0 to [rebuild] ... Done.
The 'disable' setting is permanent and cannot be changed to 'all' or 'rebuild' once it is set for the unit. As a result an extra query has been added for the user to confirm the change. If the user confirms, this is the scenario:
//localhost> /c1/u0 set rapidrecovery=disable Setting Rapid RAID Recovery to disable is permanent for /c1/u0 and CANNOT be changed at a later time. Do you want to continue? Y|N [N]: y Setting Rapid RAID Recovery policy on /c1/u0 to [disable] ... Done.
If the user replies with "n" for No, the command is aborted.
With the quiet option:
//localhost> /c1/u0 set rapidrecovery=disable quiet Setting Rapid RAID Recovery policy on /c1/u0 to [disable] ... Done.
And to see the setting, subsequently:
//localhost> /c1/u0 show rapidrecovery /c1/u0 Rapid RAID Recovery policy setting = disable
User Defined LUN Sizing, or, Variable LUN Carve, is a feature that allows the user to specify variable sizes for volumes in a unit. The first volume may be considered, although not necessarily, the Boot LUN. This feature allows the user to specify up to four volumes or LUNs in a unit.
You can define the LUN sizes for these array types: RAID-0, RAID-1, RAID-10, RAID-5, RAID-50, RAID-6 and Single.
To specify Variable LUN Carve simply requires setting an attribute during unit creation. However, to eliminate potential confusion with the existing autocarve and carvesize commands, this section was created to describe this feature along with those commands.
If the pre-existing related commands are included, the set of LUN carve commands are the following:
/cx add ... [v0=n|vol=a:b:c:d] /cx show autocarve /cx show carvesize /cx set autocarve=on|off /cx set carvesize=[1024..32768]
Note that the first command associates with this feature, and the latter four commands have pre-existed.
While the Variable LUN Sizing feature is related to the autocarve feature, they are independent. If autocarve has been set to ON, then the sizes of the volumes for that unit are set to the specifed carve-size (or the default). The possible size of the carving is in the range of {1024..32768} GB or {1..32} TB. Specifying the size(s) of the boot or first four volumes in essense overlays these volumes with their respective sizes to that of the carved volume sizes. For example, if the carvesize has been set to 1024GB and autocarve is ON:
Autocarve=ON, carvesize=1024GB (1TB)
------+------+------+------+------+------+------+------+------+------+-------
1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 . . .
------+------+------+------+------+------+------+------+------+------+-------
If we specify the first four LUN volumes to be 2000GB, 500GB, 1024GB, and 700GB, then we have the following:
------------+---+------+----+-----+------+------+------+------+------+-------
2000 500 1024 700 896 1024 1024 1024 1024 1024 . . .
------------+---+------+----+-----+------+------+------+------+------+-------
All numbers are in units of GB. Note the while the last specified carved size was 700GB, the next carved volume is not 1024GB but,
1024GB - (remainder of last volume carved)
Or:
1024 - 128 = 896
The remainder of the last volume is 128GB because the four specified volumes totaled 4224GB which exceeds the four autocarved volumes totalling 4096GB by 128GB.
For the add command, at unit creation time the volume sizes could be specified with either the attribute v0= or vol=. With v0 only the first LUN volume size could be specified. With vol, up to four LUN volume sizes may be specified. The input of size is an integer in gigabytes (GB) and the valid range is [1..32768], the upper limit is 32TB.
If the vol=a:b:c:d attribute is used, each volume is separated by the symbol : in ascending order. That is, the integer closest to = is volume 0 (v0), followed by volume 1 (v1), volume 2 (v2), etc. The maximum that could be specified with this method is four volumes, or, up to v3.
For example, consider an 8-port controller with four drives attached. As in the following:
//localhost> show
Ctl Model Ports Drives Units NotOpt RRate VRate BBU ------------------------------------------------------------------------ c0 Geroni133/Ap 8 4 0 0 1 1 -
Encls Slots Drives Fans TSUnits ---------------------------------------- /c0/e0 4 2 1 1
//localhost> /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 NOT-PRESENT - - - - p1 NOT-PRESENT - - - - p2 OK - 372.61 GB 781422768 WD-WMAMY1661939 p3 OK - 372.61 GB 781422768 WD-WMAMY1579179 p4 OK - 372.61 GB 781422768 WD-WMAMY1662720 p5 OK - 372.61 GB 781422768 WD-WMAMY1576310 p6 NOT-PRESENT - - - - p7 NOT-PRESENT - - - -
To create the unit and specify the LUN sizes of the first four volumes:
//localhost> /c0 add type=raid5 disk=2-5 vol=100:30:2:45
Creating new unit on Controller /c0 ... Done. The new unit is /c0/u0. Setting write cache=ON for the new unit ... Done. Setting default Command Queuing Policy for unit /c0/u0 to [on] ... Done.
After the unit creation, to see the volume sizes, a subsequent "show" command for the unit would display:
//localhost> /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 RAID-5 OK - - - 64K 1117.56 u0-0 DISK OK - - p2 - 372.519 u0-1 DISK OK - - p3 - 372.519 u0-2 DISK OK - - p4 - 372.519 u0-3 DISK OK - - p5 - 372.519 u0/v0 Volume - - - - - 100 u0/v1 Volume - - - - - 30 u0/v2 Volume - - - - - 2 u0/v3 Volume - - - - - 45 u0/v4 Volume - - - - - 940.56
The Verify function is among other self-test functions such as Rebuild and Selftest in the RAID system. It performs data integraty checks on an array unit based on the unit type. For a RAID-1 array, for example, the verification involves checking that both drives contain the exact data; and on a RAID-5 array, the parity information is used to verify data integrity.
This feature is available on 9000 series controllers. The Verify function requires some initial setup. Particularly the scheduled time windows of the background verify tasks need to be defined. A scheduled time window, or, timeslot, is part of the Verify Schedule.
SET UP
For the Verify function, the following commands are used for the set up:
/cx set verify=enable|disable|1..5 /cx add verify=ddd:hh:duration /cx del verify=slot_id
The setup consists of setting Verify to enable, then adding verify timeslots into the Schedule. The Schedule contains a default set of verify timeslots defined, so specifying the verify timeslots is not necessary if the defaults are suitable.
When a verify background process would initiate and run depends on more than the Schedule itself. The sections below describe this in more detail.
AUTOVERIFY
Related to this Verify function is autoverify. The Autoverify setting lets the RAID firmware determine a time to start the verify process of a unit automatically or at its discretion at a time suitable (but related to the Schedule) when it is set to ON. If a verify process has started and the verify task cannot complete within the scheduled window, the verify task would be paused and resumed later. Again, firmware makes its decision autonomously based on factors such as the schedule, settings, and other higher priority background tasks.
Autoverify applies to 9000 series controllers also.
The commands associated with Autoverify are the following:
- /cx/ux set autoverify=on|off - /cx/ux show autoverify
Autoverify is also an attribute that could be set at unit creation. The setting of autoverify is ON if Basic Verify (see Verify - Basic section) is supported, otherwise the default is set to OFF.
MANUAL VERIFY
Also related to the Verify function is Manual verify, where a background verify process or task for a unit could be started and stopped manually. The following is the set of commands associated with this:
/cx/ux start verify /cx/ux stop verify
Note that if subsequent to this command, one enables the background verify task to follow the scheduled slots, then this on-demand task will be paused until the next scheduled timeslot.
VERIFY STATUS
Finally, to see the status of the tasks associated with the Verify function, the set of commands for that is the following:
show verify /cx show verify /cx/ux show verifystatus /cx/ux show autoverify
Here is an example of the show verify command.
//localhost> /c2 show verify
Verify Schedule for Controller /c2 ======================================================== Slot Day Hour Duration Status -------------------------------------------------------- 1 Tue 6:00pm 4 hr(s) enabled 2 Wed 6:00pm 1 hr(s) enabled 3 Thu 10:00am 1 hr(s) enabled 4 Wed 4:00pm 1 hr(s) enabled 5 Thu 5:00pm 1 hr(s) enabled 6 Fri 3:00pm 1 hr(s) enabled 7 Fri 6:00pm 1 hr(s) enabled
For other examples of the Verify commands, please see the Primary Command Syntax section of this document.
Since these set of commands are related but serve different functions with respect to Verify, how they work together determines when a background verify process would initiate and run. Thus it is important to note their interactions. The following table summarizes the setting parameters and corresponding system response relative to the Verify function and when a verify task may run.
-------------+----------------------+------------------------+------------------------
Cmd: Unit-> | /cx/ux autoverify=ON | /cx/ux autoverify=OFF | /cx/ux verify=start
Cmd: Cntlr | | |
-------------+----------------------+------------------------+------------------------
/cx verify= | Verify task may run, | The verify task of the | Starts a verify task
disable | but would not be | specified unit with | immediately (regard-
| according to verify | autoverify=off would | less of autoverify
| schedule. | not run, unless an | setting).
| | on-demand (start veri- |
| | fy) command is issued. |
| | Also, other units' |
| | verify task may run. |
-------------+----------------------+------------------------+------------------------
/cx verify= | Verify task would | The verify task of the | Initiates the verify
enable | run at any time dur- | specified unit with | process that would
| ing the speicifed | autoverify=off would | start a verify task
| schedule window, | not run, unless an | depending on schedule
| provided no higher | on-demand (start veri- | (i.e., if command is
| background tasks | fy) command is issued. | issued outside of the
| would be running. | Also, other units' | schedule window, until
| | verify tasks may run. | the associated timeslot
| | | is reached in time to
| | | run, the verify task
| | | will be paused).
-------------+----------------------+------------------------+------------------------
Please note that the command /cx/ux start verify is associated with Manual Verify only when Verify=Disable. When Verify=Enable, it does not necessarily start the verify task immediately.
Advanced Verify is actually the Verify function of the previous section, intended for advanced users, in systems where Basic Verify is supported. Advanced/Basic Verify is supported on 9650SE and 9690SA controllers. In such systems, to set to Advanced Verify as opposed to Basic Verify, you would set verify=advanced with the command:
/cx set verify=advanced|basic|1..5
If the system does not support Advanced/Basic Verify, you would get the following error:
//localhost> /c2 set verify=advanced Error: (CLI:146) Basic/Advanced Verify is not supported.
In this case you could still set Verify to enable/disable. (See previous section.) If Advanced/Basic is supported on your system, after issuing this command, all other commands for Advanced Verify is identical to Verify that was presented in the previous section.
We will show a setup scenario to demonstrate how the commands are used with respect to this feature. For a RAID system with the following arrays and drives, we will show the usage of the commands along with examples. Please note that this system has a 9690SA controller with the firmware that also supports Basic Verify.
//localhost> /c3 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 298.002 ON OFF u1 SPARE OK - - - 34.1744 - OFF
VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1 p2 OK u0 149.05 GB SATA 2 - WDC WD1600JS-22NCB1 p3 OK u0 149.05 GB SATA 3 - WDC WD1600JS-22NCB1 p6 OK u1 34.18 GB SAS 6 - SEAGATE ST936701SS
First we issue /cx set verify=advanced:
//localhost> /c3 set verify=advanced Enabling scheduled verifies on controller /c3 ... Done.
We could issue a show command to see the default verify schedule:
//localhost> /c3 show verify
Verify Schedule for Controller /c3 ======================================================== Slot Day Hour Duration AdvVerify -------------------------------------------------------- 1 Sun 12:00am 24 hr(s) on 2 Mon 12:00am 24 hr(s) on 3 Tue 12:00am 24 hr(s) on 4 Wed 12:00am 24 hr(s) on 5 Thu 12:00am 24 hr(s) on 6 Fri 12:00am 24 hr(s) on 7 Sat 12:00am 24 hr(s) on Since the schedule is full, we need to delete a timeslot first, before we could add a new one with a different schedule. We will delete timeslot-3.
//localhost> /c3 del verify=3 Removing scheduled verify slot [3] ... Done.
Now to add a new background verify task onto the schedule:
//localhost> /c3 add verify=sun:15:4 Adding scheduled verify to slot 3 for [Sun, 3:00PM, 4hr(s)] ... Done.
Now the schedule would show:
//localhost> /c3 show verify
Verify Schedule for Controller /c3 ======================================================== Slot Day Hour Duration AdvVerify -------------------------------------------------------- 1 Sun 12:00am 24 hr(s) on 2 Mon 12:00am 24 hr(s) on 3 Tue 5:00pm 4 hr(s) on 4 Wed 12:00am 24 hr(s) on 5 Thu 12:00am 24 hr(s) on 6 Fri 12:00am 24 hr(s) on 7 Sat 12:00am 24 hr(s) on
To see the autoverify setting and then set it to ON for our RAID-5 array:
//localhost> /c3/u0 show autoverify /c3/u0 Auto Verify Policy = off
//localhost> /c3/u0 set autoverify=on Setting Auto-Verify Policy on /c3/u0 to [on] ... Done.
If we issue a start verify to unit /u3:
//localhost> /c3/u0 start verify Sending start verify message to /c3/u0 ... Done. Unit was not previously initialized. Will be initialized first before verified.
If we subsequently look at unit /u3 (on Tuesday, 12:30PM):
//localhost> /c3 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 INITIALIZING - 0% 64K 298.002 ON ON u1 SPARE OK - - - 34.1744 - OFF
VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1 p2 OK u0 149.05 GB SATA 2 - WDC WD1600JS-22NCB1 p3 OK u0 149.05 GB SATA 3 - WDC WD1600JS-22NCB1 p6 OK u1 34.18 GB SAS 6 - SEAGATE ST936701SS
Note that the initialize process is starting.
The table below summarizes the settings for Advanced Verify. It describes the interactions of the commands and the corresponding system response.
-------------+----------------------+------------------------+------------------------
Cmd: Unit-> | /cx/ux autoverify=ON | /cx/ux autoverify=OFF | /cx/ux verify=start
Cmd: Cntlr | | |
-------------+----------------------+------------------------+------------------------
/cx verify= | Verify task would | The verify task of the | Initiates the verify
advanced | run at any time dur- | specified unit with | process that would
| ing the specifed | autoverify=off would | start a verify task
| schedule window, | not run, unless an | depending on schedule
| provided no higher | on-demand (start veri- | (i.e., if command is
| background tasks | fy) command is issued. | issued outside of the
| would be running. | Also, other units' | schedule window, until
| | verify tasks may run. | the associated timeslot
| | | is reached in time to
| | | run, the verify task
| | | be paused).
-------------+----------------------+------------------------+------------------------
Please note that this is the lower part of the table in the previous section on Verify, with verify=advanced instead of verify=enabled.
As a result of the complexity and non-deterministic nature of Verify or Advanced Verify with respect to when scheduled verify tasks may execute, the Basic Verify feature was introduced to provide a more simplistic verify function as an option.
Basic Verify does not change the current Verify function. But supplies the user a means to specify a preferred day and time for a weekly background verify task to be executed. If the preferred day and time is not specified, a default is provided. The setting is simplier and when a scheduled verify task would run is more deterministic and straight-forward.
Before using Basic Verify, it is important to know if your system supports Advanced/Basic Verify. Generally, this is supported in the 9650SE, 9690SA and 9750 controllers. If the system does not support Advanced/Basic Verify, you would get the following error:
//localhost> /c2 set verify=advanced Error: (CLI:146) Basic/Advanced Verify is not supported for the specified controller.
The table below summarizes the settings for Basic Verify. It describes the interactions of the commands and the corresponding system response.
-------------+----------------------+------------------------+------------------------
Cmd: Unit-> | /cx/ux autoverify=ON | /cx/ux autoverify=OFF | /cx/ux verify=start
Cmd: Cntlr | | |
-------------+----------------------+------------------------+------------------------
/cx verify= | The verify task | The verify task of the | Starts a verify task
basic | would run according | specified unit with | immediately (regard-
| to the specified | autoverify=off would | less of autoverify
| preferred time (if | not run, unless an | setting).
| none is specified, | on-demand (start veri- |
| default is used). | fy) command is issued. |
| | Other units' verify |
| | tasks may run. |
-------------+----------------------+------------------------+------------------------
To set the background verify task with Basic Verify, specify verify=basic along with the preferred day and time for the verify task to execute:
//localhost> /c3 set verify=basic pref=Fri:23 Setting /c3 basic verify preferred start time to [Fri, 11:00PM] ... Done.
To display the preferred start time and day of the verify task previously set:
//localhost>> /c0 show verify /c0 basic verify weekly preferred start: Friday, 11:00PM
The background verify task will run every Friday starting at 11:00 PM.
While informative messages are written to standard output, error messages are written to standard error. On success, 0 is returned. On failure 1 is returned.
If you wish to use CLI in single command mode (not interactive), make sure to avoid collision with your command interpreter (OS shell) by escaping the meta-characters (such as ?, <, >, @, &, *, etc) appropriately with single quote around them.
For example, given the
$ tw_cli /c0 ?
This is a case of single command usage where the user intends to get help on Controller
related commands. While this is a valid CLI command, but since the arguments to CLI
are first processed by the shell, then some shells like csh(1) will interpret the '?' as
a meta-character to be used toward file completion and if no file is found with a single
character, then shell will complain before the arguments are even passed down to CLI.
One solutions of this problem can be :
$ tw_cli help /cx
or
$ tw_cli '/c0 ?'
Note: Some of the OS shell does not have this problem such as bash.
tw_cli(8) reporting has changed (hopefully for better). The intent has been to provide a consistent tabular reporting so that relevant and important information (such as B<info>) are made available as fast as possible. For example, firmware, PCB, PCHIP and similar information have been removed from the info summary report, as this type of information is not frequently needed.
The new style also accommodates automation much better by providing consistent columns with or without values so that it could be easily parsed. The intent is to make CLI yet another API (to approach it).
However to accommodate current automations around tw_cli and to ease the migration, the old behavior can still be requested by setting TW_CLI_STYLE environment variable to OLD as follows:
If Bash, then "export TW_CLI_STYLE=OLD" If csh, then "setenv TW_CLI_STYLE OLD" if Windows, then "set TW_CLI_STYLE=OLD"
This backward compatibility window, will be communicated by official 3ware representatives.
On the 9K series of controllers, the rebuild scheduling controls both rebuild and
initialize processes if it is enabled. Currently, tw_cli(8)
does not have any direct command to pause or resume an initialization process.
If such action is needed, use the rebuild scheduling to handle it.
TW_CLI_STYLE setting this variable to OLD, will provide the old reporting style. TW_CLI_INPUT_STYLE setting this variable to OLD, will disable focus feature in the interactive mode.
This document was written, augmented, and modified over time by developers of the Command Line Interface (CLI) software.
3ware SAS/SATA RAID Software User Guide 3ware SAS+SATA RAID Controller Card CLI Guide 3ware Installation Guide http://www.3ware.com or http://www.lsi.com/channel