.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14 .\" .\" Standard preamble: .\" ======================================================================== .de Sh \" Subsection heading .br .if t .Sp .ne 5 .PP \fB\\$1\fR .PP .. .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' .\" expand to `' in nroff, nothing in troff, for use with C<>. .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' 'br\} .\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . nr % 0 . rr F .\} .\" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] \fP .\} .if t \{\ . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff .if n \{\ . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} .if t \{\ . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' .ds 8 \h'\*(#H'\(*b\h'-\*(#H' .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] .ds ae a\h'-(\w'a'u*4/10)'e .ds Ae A\h'-(\w'A'u*4/10)'E . \" corrections for vroff .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' . \" for low resolution devices (crt and lpr) .if \n(.H>23 .if \n(.V>19 \ \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} .rm #[ #] #H #V #F C .\" ======================================================================== .\" .IX Title "TW_CLI 8" .TH TW_CLI 8 "2012-09-24" "Version " "3ware Storage Management CLI" \&\fItw_cli\fR\|(8) \- 3ware Storage Controller Management Command Line Interface (\s-1CLI\s0) manpage / \s-1HTML\s0 Help Document Version 3.1. .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 3 \& tw_cli Interactive Mode \& tw_cli -f file Process from a file \& tw_cli command Process single command (batch mode) .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" \&\fI\fItw_cli\fI\|(8)\fR is a Command Line Interface Storage Management Software for 3ware \s-1ATA\s0 \s-1RAID\s0 Controller(s). It provides controller, logical unit and drive management. tw_cli can be used in both interactive and batch mode, providing higher-level \s-1API\s0 (Application Programming Interface) functionalities. .PP The \s-1CLI\s0 prompt indicates the current object in focus, expressed in \s-1URI\s0 (Universal Resource Identifier) syntax consisting of a hostname (\fI//hostname\fR), and an object path (\fI/path/path/object\fR) such as \fI//elvis/c0/u0\fR. User can set the focus to a particular object by \fIfocus \s-1URI\s0\fR. .PP \&\s-1CLI\s0 also supports \fIcomments\fR. Command lines beginning with \fI#\fR denotes start of comment. This feature is mostly useful with batch processing via \fI\-f script\fR flag. .PP \&\s-1CLI\s0 uses the following terminology: .PP \&\fBLogical Units.\fR Usually shortened to \*(L"units\*(R", 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. \&\s-1RAID\-1\s0 and \s-1RAID\-5\s0 are examples of two-tier units and as such will have sub\-units. \s-1RAID\-10\s0 and \s-1RAID\-50\s0 are examples of three-tier units and as such will have sub\-sub\-units. .PP \&\fBPort.\fR 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). .PP \&\fBPhy.\fR 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 \*(L"controller phys\*(R" are associated with virtual ports (vports) to establish up to 128 potential connections with the \s-1SAS\s0 or \s-1SATA\s0 drives. Each controller phy can be connected to a single drive, or can be connected through an expander to additional drives. .PP \&\fBVPort.\fR Connections from the 9690SA and 9750 controllers to drives are referred to as \fIvirtual ports\fR, or vports. A vport indicates the \s-1ID\s0 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 \s-1ID\s0 or vport \s-1ID\s0 allows a drive to be consistently identified, used and managed in a \s-1RAID\s0 unit. For dual-ported drives, although there are two connections to a drive, the drive is still identified with one vport handle. \fBNote:\fR With the controller summay via the command \*(L"show\*(R", 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 \*(L"/cx show\*(R" contains only the number of vports corresponding to the number of drives. This is because the drive is identified with only one vport handle. .PP \&\fB\s-1NOTE:\s0\fR 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 \*(L"port\*(R" is mentioned to denote a drive, it is implied that for the applicable controller series, the reference also applies to vport. .PP \&\s-1CLI\s0 supports a set of primary command syntax and a set of legacy command syntax that is the old or original command syntax. \fBNote:\fR The primary command syntax replaces that legacy command syntax and as such support for legacy commands will discontinue in the near future. .PP Please also note that some of the commands listed in this document are qualified with restrictions of controller type/model support. For example, \*(L"9000 series\*(R" or \&\*(L"9550SX and higher\*(R" may be next to a command. The following is a summary of the controller qualified specifications. .PP Commands with: .PP .Vb 7 \& 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. .Ve .PP 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). .PP Here is a summary of the controllers and their associated support: .PP .Vb 19 \& 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 \& ----------------+------------------------------------------- .Ve .PP Please note that the support items are accumulative down the list, excepted where noted. Also, \s-1CCU\s0 (Chassis Control Unit) refers to the \s-1JMR\s0 enclosure/Sidecar. .PP This document organizes the \s-1CLI\s0 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 \&\*(L"set\*(R" command and correspondingly displayed with a \*(L"show\*(R" 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 \fBFeatures\fR section of this document. .PP 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 \fBPrimary Command Syntax\fR sections, and for the latter please see the Features sections. .SH "Primary Command Syntax" .IX Header "Primary Command Syntax" 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: .PP .Vb 1 \& Object Message Attributes .Ve .PP 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 \*(L"show\*(R", 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 \fIBoolean Attributes\fR or \fINamed Attributes\fR. Value of a Boolean attribute is deduced by presence. Value of named attributes are expressed in a \*(L"key = value\*(R" format. .Sh "Shell Object Messages" .IX Subsection "Shell Object Messages" Shell Object Messages are commands (a.k.a. methods/messages) that are sent to the Command Interpreter (a.k.a. Shell/CLI) itself. .RE .IP "\fIshow\fR" .IX Item "show" 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. .PP Typical output looks like: .PP .Vb 1 \& //localhost> show .Ve .PP .Vb 4 \& 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 .Ve .PP The output indicates that \fIController 0\fR 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), \s-1BBU\s0 of '\-' (Not Applicable). Not Optimal refers to any state except \s-1OK\s0 and \s-1VERIFYING\s0. Other states include \s-1INITIALIZING\s0, \s-1INIT\-PAUSED\s0, \s-1REBUILDING\s0, \s-1REBUILD\-PAUSED\s0, \s-1DEGRADED\s0, \&\s-1MIGRATING\s0, \s-1MIGRATE\-PAUSED\s0, \s-1RECOVERY\s0, \s-1INOPERABLE\s0, and \s-1UNKNOWN\s0. .PP 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: .PP .Vb 1 \& //localhost> show .Ve .PP .Vb 3 \& Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU \& --------------------------------------------------------------------------- \& c0 G133e/Astor 12 4 1 0 1 1 - .Ve .PP .Vb 3 \& Encl Slots Drives Fans TSUnits PSUnits \& -------------------------------------------------- \& /c0/e0 4 2 1 1 1 .Ve .PP 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. .RE .IP "\fBshow\fR \fIver\fR" .IX Item "show ver" This command will show the \s-1CLI\s0 and \s-1API\s0 version. .PP For example: .PP .Vb 1 \& //localhost> show ver .Ve .PP .Vb 2 \& CLI Version = 2.00.03.018 \& API Version = 2.01.00.004 .Ve .RE .IP "\fBshow\fR \fIevents\fR [\fIreverse\fR]" .IX Item "show events [reverse]" .RE .PD 0 .IP "\fBshow\fR \fIAENs\fR [\fIreverse\fR]" .IX Item "show AENs [reverse]" .RE .IP "\fBshow\fR \fIalarms\fR [\fIreverse\fR]" .IX Item "show alarms [reverse]" .PD This command shows the controller alarms or events, also known as \s-1AEN\s0 (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 \fIreverse\fR attribute reverses this order and shows the most recent alarm at the top of the table. For more information please see '\fI/cx show AENs\fR'. .RE .IP "\fBshow\fR \fIdiag\fR" .IX Item "show diag" This command shows the diagnostic information of all controllers in the system. .RE .IP "\fBshow\fR \fIrebuild\fR" .IX Item "show rebuild" This command displays all rebuild schedules of all the 9000 controllers in the system. .RE .IP "\fBshow\fR \fIselftest\fR" .IX Item "show selftest" This command displays all self test schedules of all the 9000 controllers in the system. .RE .IP "\fBshow\fR \fIverify\fR" .IX Item "show verify" This command displays all verify schedules of all the 9000 controllers in the system. .RE .IP "\fBupdate\fR \fIfw=filename_with_path\fR [\fIforce\fR]" .IX Item "update fw=filename_with_path [force]" 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 \fI/cx update fw=filename_with_path [force]\fR for detail. .RE .IP "\fBfocus\fR \fIObject\fR" .IX Item "focus Object" 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 .PP .Vb 1 \& //hostname/c0/u0 show .Ve .PP Instead, if the focus is set to \fI//hostname/c0/u0\fR, the prompt is changed automatically to reflect this and the user would only have to type \fIshow\fR. The concept is similar to being in a particular location in a file system and requesting a listing of the current directory. .PP \&\fIobject\fR can have the following forms: .PP \&\fI//hostname/cx/ux\fR specifies the fully qualified \s-1URI\s0 of an object on host \&\fBhostname\fR, controller \fBcx\fR, unit \fBux\fR. .PP \&\fI//hostname\fR specifies root of host \fBhostname\fR. The hostname is the name of the system where your 3ware \s-1RAID\s0 controllers are. With current releases, the hostname here should be always your system's name. .PP \&\fI..\fR specifies one level up (the parent object). .PP \&\fI/\fR specifies the root at the current focused host. .PP \&\fI./obj\fR specifies the next level of the object. .PP \&\fI/c0/bbu\fR specifies a relative path with respect to the current focused hostname. .PP For example: .PP .Vb 2 \& //localhost> focus //elvis.3ware.com \& //elvis.3ware.com> .Ve .PP .Vb 2 \& //elvis.3ware.com> focus /c0/u0 \& //elvis.3ware.com/c0/u0> .Ve .PP .Vb 2 \& //elvis.3ware.com/c0/u0> focus .. \& //elvis.3ware.com/c0> .Ve .PP .Vb 2 \& //elvis.3ware.com/c0> focus ./u0 \& //elvis.3ware.com/c0/u0> .Ve .PP .Vb 2 \& //elvis.3ware.com/c0> focus / \& //elvis.3ware.com> .Ve .PP Note that \fIfocus\fR is available as default. You can also set \fITW_CLI_INPUT_STYLE=OLD\fR in the following to disable the feature. .PP .Vb 3 \& 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" .Ve .Sh "Controller Object Messages" .IX Subsection "Controller Object Messages" Controller Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller such as \fI/c0\fR. .RE .IP "\fI/cx\fR \fBshow\fR" .IX Item "/cx show" This command shows summary information on the specified controller \fI/cx\fR. This report consists of two to three parts: the \fBUnit Summary\fR that lists all units present, the \fBPort Summary\fR that lists the ports and disks attached to them, and if a \s-1BBU\s0 unit is installed, the \fB\s-1BBU\s0 Summary\fR that shows information on the \s-1BBU\s0. .PP The \fBUnit Summary\fR section lists the units present with the unit number, unit type (such \s-1RAID\s0 5), and unit status (such as \s-1OK\s0, \s-1VERIFYING\s0, \s-1INITIALIZING\s0, etc.). The \fB%RCompl\fR reports the percent completion of the unit's Rebuild, if this task is in progress. The \fB%V/I/M\fR 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. .PP \&\fBNote\fR: If a \*(L"*\*(R" 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. .PP For controller models up to the 9550SX and 9650SE with Release 9.5.1 or earlier, the \fBPort Summary\fR 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. .PP 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. .PP \&\fBNote\fR: 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. .PP The \fB\s-1BBU\s0 Summary\fR section lists the online state, readiness, and status of the \s-1BBU\s0 unit, along with the voltage, temperature, charge capacity expressed as time remaining in hours, and the \s-1BBU\s0's last test date. .PP Additional attributes about controllers, units, ports and disks can be obtained by querying for them directly. See other show sub-commands below. .PP Here is the typical output for controller models up to 9550SX and 9650SE with Release 9.5.1 or earlier: .PP .Vb 1 \& //localhost> /c2 show .Ve .PP .Vb 6 \& 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 .Ve .PP .Vb 14 \& 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 .Ve .PP .Vb 3 \& Name OnlineState BBUReady Status Volt Temp Hours LastCapTest \& --------------------------------------------------------------------------- \& bbu On Yes OK OK OK 241 22-Jun-2004 .Ve .PP Here is the typical output for the 9750, 9690SA and 9650SE controller with Release 9.5.2 or later: .PP .Vb 4 \& 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 .Ve .PP .Vb 6 \& 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 .Ve .PP \&\fBNote:\fR 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 \&\*(L"older\*(R" controllers, this column shows the state (\s-1ON\s0 or \s-1OFF\s0) of the write cache only. For the \*(L"newer\*(R" controllers, the 'Cache' column displays the settings of both the read cache and the write cache. For example: .PP .Vb 5 \& 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 .Ve .PP 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 \s-1OFF\s0 is shown then all caches are disabled. .PP Below is a summary of the possible settings in that column: .PP .Vb 6 \& 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 .Ve .PP \&\fBNote:\fR If read cache Intelligent is enabled, the features in the Basic mode are also enabled. .RE .IP "\fI/cx\fR \fBshow\fR Attribute Attribute ..." .IX Item "/cx show Attribute Attribute ..." This command shows the current setting of the given \fIattribute(s)\fR. 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. .RE .IP "\fI/cx\fR \fBshow\fR \fIdriver\fR" .IX Item "/cx show driver" This command reports the device driver version associated with controller \&\fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show driver \& /c0 Driver Version = 1.02.00.036 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fImodel\fR" .IX Item "/cx show model" This command reports the controller model of controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show model \& /c0 Model = 7500-12 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIfirmware\fR" .IX Item "/cx show firmware" This command reports the firmware version of controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show firmware \& /c0 Firmware Version = FE9X 3.03.06.X03 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIbios\fR" .IX Item "/cx show bios" This command reports the \s-1BIOS\s0 version of controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show bios \& /c0 BIOS Version = BG9X 2.01.00.026 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fImonitor\fR" .IX Item "/cx show monitor" This command reports the monitor (firmware boot\-loader) version of controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show monitor \& /c0 Monitor Version = BLDR 1.00.00.008 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIserial\fR" .IX Item "/cx show serial" This command reports the serial number of the specified controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show serial \& /c0 Serial Number = F12705A3240009 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIpcb\fR" .IX Item "/cx show pcb" This command reports the \s-1PCB\s0 (Printed Circuit Board) revision of the specified controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show pcb \& /c0 PCB Version = Rev3 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIpchip\fR" .IX Item "/cx show pchip" This command reports the \s-1PCHIP\s0 (\s-1PCI\s0 Interface Chip) version of the specified controller \fI/cx\fR. .PP Example: .PP .Vb 1 \& //localhost> /c0 show pchip .Ve .PP .Vb 1 \& /c0 PCHIP Version = 1.30-33 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIachip\fR" .IX Item "/cx show achip" This command reports the \s-1ACHIP\s0 (\s-1ATA\s0 Interface Chip) version of the specified controller \fI/cx\fR. .PP Example: .PP .Vb 1 \& //localhost> /c0 show achip .Ve .PP .Vb 1 \& /c0 ACHIP Version = 3.20 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fInumports\fR" .IX Item "/cx show numports" For controller models earlier than the 9690SA, this command reports the port capacity (number of physical ports) of the specified controller \fI/cx\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 show numports \& /c0 Number of Ports = 12 .Ve .PP For the 9750 and 9690SA controllers, this command reports the connections and connection capacity of the specified controller \fI/cx\fR. Connections consist of vports and phys. .PP Example: .PP .Vb 2 \& //localhost> /c3 show numports \& /c3 Connections = 4 of 128 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fInumunits\fR" .IX Item "/cx show numunits" This command reports the number of units currently managed by the specified controller \fI/cx\fR. This report does not include off-line units (or removed units). .PP Example: .PP .Vb 2 \& //localhost> /c0 show numunits \& /c0 Number of Units = 1 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fInumdrives\fR" .IX Item "/cx show numdrives" This command reports the number of drives currently managed by the specified controller \fI/cx\fR. 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 \fB/cx/px show smart\fR for a workaround. .PP Example: .PP .Vb 2 \& //localhost> /c0 show numdrives \& /c0 Number of Drives = 5 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIspinup\fR (9000 series)" .IX Item "/cx show spinup (9000 series)" This command presents the number of concurrent disks spin up at the power on. .PP Example: .PP .Vb 1 \& //localhost> /c0 show spinup .Ve .PP .Vb 1 \& /c0 Disk Spinup Policy = 1 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIondegrade\fR (9500S only)" .IX Item "/cx show ondegrade (9500S only)" This command presents the write cache policy for degraded units. If the ondegrade policy is \fBFollow Unit Policy\fR, a unit write cache policy stays the same when the unit becomes degraded. If the ondegrade policy is \fBoff\fR, a unit cache policy will force to be off when the unit becomes degraded. .PP Example: .PP .Vb 2 \& //localhost> /c0 show ondegrade \& /c0 Cache on Degraded Policy = Follow Unit Policy .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIstagger\fR (9000 series)" .IX Item "/cx show stagger (9000 series)" This command presents the time delay between each group of spinups at the power on. .PP Example: .PP .Vb 2 \& //localhost> /c0 show stagger \& /c0 Spinup Stagger Time Policy (sec) = 2 .Ve .PP See also: .PP .Vb 3 \& /cx set stagger=nn \& /cx set spinup=nn \& /cx show spinup .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIautocarve\fR (9550SX and higher)" .IX Item "/cx show autocarve (9550SX and higher)" 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 \s-1TB\s0. .PP This feature is useful for operating systems limited to 2 \s-1TB\s0 filesystems. For 64\-bit \s-1OS\s0 users, there is no need to set the policy to be \*(L"on\*(R" unless users want to have multiple smaller volumes to the \s-1OS\s0. For 32\-bit \s-1OS\s0 users, it is recommended to keep the policy on unless users know their \s-1OS\s0 supports more than 2 \s-1TB\s0 disk devices. .PP When autocarve policy is off, all the new unit creation consists of one single volume. .PP Example: .PP .Vb 2 \& //localhost> /c0 show autocarve \& /c0 Auto-Carving Policy = on .Ve .PP See also: .PP .Vb 3 \& /cx set autocarve= \& /cx set carvesize=<1024..32768> \& /cx show carvesize` .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIcarvesize\fR (9550SX and higher)" .IX Item "/cx show carvesize (9550SX and higher)" This command shows the carvesize that Auto-Carving policy needs. The carve size is between 1024 to 32768 \s-1GB\s0 (i.e., 1TB\-32TB). Default carvesize is 2048 \s-1GB\s0 (i.e., 2TB). See "\fI/cx\fR \fBshow\fR \fIautocarve\fR" command above for details. .PP Example: .PP .Vb 2 \& //localhost> /c0 show carvesize \& /c0 Auto-Carving Size = 2000 GB .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fImemory\fR" .IX Item "/cx show memory" This command presents the size of the memory installed on the controller. .PP Example: .PP .Vb 2 \& //localhost> /c0 show memory \& /c0 Available Memory = 112MB .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIctlbus\fR (9550SX and higher)" .IX Item "/cx show ctlbus (9550SX and higher)" This command presents the controller host bus type, bus speed and bus width. .PP Example: .PP .Vb 1 \& //localhost> /c0 show ctlbus .Ve .PP .Vb 3 \& /c0 Controller Bus Type = PCIX \& /c0 Controller Bus Width = 64 bits \& /c0 Controller Bus Speed = 133 Mhz .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIautorebuild\fR (9550SX and higher)" .IX Item "/cx show autorebuild (9550SX and higher)" This command shows the Auto-Rebuild policy of the specified controller. If there is a degraded unit and the policy is set to \s-1ON\s0, the controller firmware will choose drives in the following order of priority, for a drive candidate to perform the rebuild operation: .PP 1. Smallest usable capacity spare. .PP 2. Smallest usable unconfigured drive. .PP 3. Smallest usable capacity failed drive. .PP If the policy is set to \s-1OFF\s0, spare drives are the only candidates for an automatic rebuild operation. .PP Example: .PP .Vb 2 \& //localhost> /c0 show autorebuild \& /c0 Auto-Rebuild Policy = on .Ve .PP See also: .PP .Vb 1 \& /cx set autorebuild= .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIdpmstat\fR [type=inst|ra] (9550SX and higher)" .IX Item "/cx show dpmstat [type=inst|ra] (9550SX and higher)" .RE .PD 0 .IP "\fI/cx\fR \fBshow\fR \fIdpmstat\fR [type=inst|ra|ext] (9650SE and higher)" .IX Item "/cx show dpmstat [type=inst|ra|ext] (9650SE and higher)" .PD 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. .PP The optional 'type' in the command specifies which statistics would be displayed. The options are either: \fBinst\fR for Instantaneous, \fBra\fR for Running Average, and \fBext\fR 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'. .PP For example: .PP .Vb 7 \& //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 .Ve .PP .Vb 11 \& 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 - - - - - .Ve .PP 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. .PP Also, for examples of other statistic data types, please see the 'Features' section. .RE .IP "\fI/cx\fR \fBshow\fR \fIunitstatus\fR" .IX Item "/cx show unitstatus" This command presents a list of units, their types, capacity and status currently managed by the specified controller \fI/cx\fR. .PP Example: .PP .Vb 1 \& //localhost> /c2 show unitstatus .Ve .PP .Vb 6 \& 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 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIallunitstatus\fR" .IX Item "/cx show allunitstatus" This command presents a count of Total and Not Optimal units managed by the specified controller \fI/cx\fR. See \*(L"Shell Object Messages\*(R" for more on Not Optimal definition. .PP Example: .PP .Vb 1 \& //localhost> /c0 show allunitstatus .Ve .PP .Vb 2 \& /c0 Total Optimal Units = 2 \& /c0 Not Optimal Units = 0 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIdrivestatus\fR" .IX Item "/cx show drivestatus" This command presents a list of drives, port assignment, vendor signature, size, status, and unit membership/affiliation. .PP Example: .PP .Vb 1 \& //localhost> /c0 show drivestatus .Ve .PP .Vb 14 \& 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 - - - - .Ve .RE .IP "\fI/cx\fR \fBshow all\fR" .IX Item "/cx show all" This command shows the current setting of all attributes. .RE .IP "\fI/cx\fR \fBadd\fR type= disk= [stripe=size] [noscan] [group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>] [nocache|nowrcache] [nordcache|rdcachebasic] [autoverify|noautoverify] [noqpolicy] [ignoreECC] [name=string] [storsave=] [v0=n|vol=a:b:c:d] [rapidrecovery=all|rebuild|disable]" .IX Item "/cx add type= disk= [stripe=size] [noscan] [group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>] [nocache|nowrcache] [nordcache|rdcachebasic] [autoverify|noautoverify] [noqpolicy] [ignoreECC] [name=string] [storsave=] [v0=n|vol=a:b:c:d] [rapidrecovery=all|rebuild|disable]" This command allows you to add a new unit or create a unit on the specified controller \fI/cx\fR, of type \fIRaidType\fR, optional stripe size of \fIStripe\fR, using one or many disks specified by \fIdisk=p:\-p\fR. By default the host operating system will be informed of the new block device and write cache is enabled. In case of \s-1RAID\-50\s0, you can also specify the layout of the unit by specifying the number of disks per disk group with \fIgroup=3|4|5|6|7|8\fR attribute. .PP Upon the success of the new unit creation, a unique serial number is also assigned to the new unit. Please refer to commands \fI/cx/ux show serial\fR for checking. .PP Please Note: 1) The default of the unit creation sets write cache to \*(L"on\*(R" for performance reasons. However, if there is no \s-1BBU\s0 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 \fInoqpolicy\fR. 3) The \fInoqpolicy\fR attribute is not applicable to the \*(L"spare\*(R" unit. Specifying the noqpolicy attribute returns an error. 4) The [v0=n|vol=a:b:c:d] option is not applicable to type=single. .PP Since this command is by far the richest command, it deserves more details. .PP \&\fB/cx\fR is the controller name as in /c0, /c1, etc. .PP \&\fBtype=RaidType\fR consists of logical unit type as in \fBraid0\fR, \fBraid1\fR, \&\fBraid5\fR, \fBraid10\fR, \fBraid50\fR, \fBsingle\fR, \fBspare\fR, and \fBraid6\fR (9650SE and higher only). .PP For example: .PP .Vb 1 \& type=raid50 .Ve .PP The following table illustrates supported types and controller models. .PP .Vb 10 \& 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| | | | | | | | | | \& ------+-------+-------+-------+--------+------+-------+--------+--------+-------+ .Ve .PP \&\fBdisk=p:\-p\fR 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 \fB\*(L":\*(R"\fR or \fB\*(L"\-\*(R"\fR as port index separators. A dash indicates a range and can be mixed with \*(L":\*(R". For example \&\fBdisk=0:1:2\-5:9:12\fR indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12. .PP \&\fBstripe=size\fR 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 \s-1KB\s0 (kilobytes). .PP .Vb 16 \& 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 | | | | \& ------+---------+-------+-------+-------+--------+--------+-------+-------+--------+ .Ve .PP \&\fBgroup=3|4|5|6|7|8|9|10|11|12|13|14|15|16\fR consists of the number of disks per group for a Raid 50 type. \fBNote:\fR This attribute can only be used when type=raid50. Also, group=13\-16 is applicable to the 9690SA and 9750 controllers only. .PP Recall that a \s-1RAID\-50\s0 is a multi-tier array. At the most bottom layer, N number of disks per group are used to form the \s-1RAID\-5\s0 layer. These \&\s-1RAID\-5\s0 arrays are then integrated into a \s-1RAID\-0\s0. This attribute allows you to specify the number of disks in the \s-1RAID\-5\s0 level. Valid values are 3, 4, 5, 6, 7 and 8. .PP 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 \s-1RAID\-5\s0. However given 12 disks, specifying 3 will create four \s-1RAID\-5\s0 under the \s-1RAID\-0\s0 level. Given 6 disks and grouping of 6 is not allowed, as you'll basically be creating a \s-1RAID\-5\s0. .PP 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. .PP 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. .PP \&\fBnoscan\fR attribute instructs \s-1CLI\s0 not to notify \s-1OS\s0 of creation of the new unit. By default \s-1CLI\s0 will inform the \s-1OS\s0. One application of this feature is to avoid the \s-1OS\s0 from creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and creating a moving target. .PP \&\fBnocache\fR or \fBnowrcache\fR attribute instructs \s-1CLI\s0 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 \s-1BBU\s0 or \s-1UPS\s0 is installed. The system default for the write cache is enable. If a \s-1BBU\s0 or \&\s-1UPS\s0 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. .PP \&\fBnordcache\fR attribute instructs \s-1CLI\s0 to disable the read cache on the newly created unit. Enabling the read cache increases performance. The \fBrdcachebasic\fR attribute instructs \s-1CLI\s0 to set the read cache mode on the newly created unit to \fIBasic\fR. Please note that it is not necessary to include any read cache attribute if you wish to select the \fIIntelligent\fR mode of Read Cache, since the system default is Read Cache Intelligent. See \*(L"/cx/ux set rdcache\*(R" for more information. .PP \&\fBautoverify|noautoverify\fR 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 \fI/cx/ux set autoverify\fR 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 \s-1ON\s0 by default for the new unit to be created. For other 9000 series controllers that do not support Basic Verify, autoverify is set to \s-1OFF\s0 by default for the new unit. The following table should help clarify regarding the defaults: .PP .Vb 13 \& ---------------------+--------------------+---------------------- \& "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 \& ---------------------+--------------------+---------------------- .Ve .PP .Vb 2 \& *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. .Ve .PP \&\fBNote\fR: while there is no reason to issue both \fIautoverify\fR and \fInoautoverify\fR together at unit creation, \s-1CLI\s0 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. .PP \&\fBnoqpolicy\fR attribute instructs \s-1CLI\s0 to disable the qpolicy (drive queuing) on the newly created unit. The default qpolicy is \fIon\fR (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 \fInoqpolicy\fR for spare returns an error. .PP \&\fBignoreECC\fR attribute enables the ignoreECC/OverwriteECC attribute on the unit that is to be created. For more details on this feature, refer to \fI/cx/ux set\fR 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. .PP .Vb 10 \& 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 | | | | | | | | | | \& --------+-------+-------+-------+-------+--------+------+-------+--------+--------+ .Ve .PP \&\fBname=string\fR 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 \s-1OS\s0 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 \fI/cx/ux set name=sting\fR for changing the name and \fI/cx/ux show name\fR for checking. .PP \&\fBstorsave=protect|balance|perform\fR 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 \fI/cx/ux set storsave=protect|balance|perform\fR for detail. .PP Either the \fBv0=n\fR or \fBvol=a:b:c:d\fR 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 \s-1LUN\s0. The value(s) should be positive integer(s) in units of gigabytes (\s-1GB\s0). Zero (0) is an invalid \s-1LUN\s0 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. .PP \&\fBNote:\fR 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. .PP Example (\s-1RAID\-5\s0 being created with the first volume size set to 10 \s-1GB\s0): .PP .Vb 1 \& //localhost> /c0 add type=raid5 disk=2-5 v0=10 .Ve .PP .Vb 3 \& 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. .Ve .PP After the unit creation, a subsequent \*(L"show\*(R" command for the unit would show the volume sizes: .PP .Vb 1 \& //localhost> /c0/u0 show .Ve .PP .Vb 9 \& 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 .Ve .PP Example (\s-1RAID\-0\s0 being created with the volume sizes set to 45, 20, 50, and 12 \s-1GB\s0): .PP .Vb 1 \& //localhost> /c3 add type=raid0 disk=0-1 vol=45:20:50:12 .Ve .PP .Vb 3 \& 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. .Ve .PP After the unit creation, a subsequent \*(L"show\*(R" command for the unit would show the volume sizes: .PP .Vb 1 \& //localhost> /c3/u0 show .Ve .PP .Vb 10 \& 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 .Ve .PP The attribute \fBrapidrecovery\fR specifies the Rapid \s-1RAID\s0 Recovery setting for the unit to be created. Rapid \s-1RAID\s0 Recovery can speed up the rebuild process, and it can speed up the initialize and verify tasks for redundant arrays in the \s-1RAID\s0 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 \fIall\fR applies the policy to the rebuild, initialize and verify tasks at reboot. Setting it to \fIrebuild\fR applies the policy to the rebuild tasks only. If the policy is set to \fIdisable\fR, then none of the tasks would be sped up. .PP \&\fBNote:\fR 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. .PP \&\fBNote:\fR This attribute is for controller models 9750, 9690SA and 9650SE (with supporting firmware), and is for redundant arrays only. In addition, Rapid \s-1RAID\s0 Recovery is not supported over migration. .PP \&\fBNote:\fR The default setting of Rapid \s-1RAID\s0 Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled. .RE .IP "\fI/cx\fR \fBrescan\fR [\fInoscan\fR]" .IX Item "/cx rescan [noscan]" 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 \s-1DCB\s0 (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. \&\fInoscan\fR is used to not inform the \s-1OS\s0 of the unit discovery. Default is to inform the \s-1OS\s0. .PP Example: .PP .Vb 1 \& //localhost> /c1 rescan .Ve .PP .Vb 3 \& Rescanning controller /c1 for units and drives ...Done. \& Found following unit(s): [/c1/u3]. \& Found following drive(s): [/c1/p7, /c1/p8]. .Ve .PP Note: Does not import non-JBOD on 7000/8000 models. .RE .IP "\fI/cx\fR \fBcommit\fR" .IX Item "/cx commit" 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. .PP 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 \s-1UPS\s0 post failure automations). This command can then expedite the process by instructing the controller to finish pending requests, clear \&\s-1DCB\s0's in-transaction flag as we are going down. .PP 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. .PP This command only applies to Windows operating system. .RE .IP "\fI/cx\fR \fBflush\fR" .IX Item "/cx flush" This command allows you to flush the write cache on all units associated with the \fI/cx\fR controller .RE .IP "\fI/cx\fR \fBupdate\fR \fIfw=filename_with_path\fR [\fIforce\fR]" .IX Item "/cx update fw=filename_with_path [force]" This command allows the download of the specified firmware image to the corresponding controller. This command is for 9000 series controllers only. .PP \&\fBfw=filename_with_path\fR attribute allows the user to specify the firmware image file name along with its path. Please note that \fIfilename_with_path\fR could not have spaces in the directory names of its path (as Windows would allow). .PP The new image specified by \fIfilename_with_path\fR 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. .PP Example: .PP .Vb 1 \& //localhost> /c2 update fw=/tmp/prom0006.img .Ve .PP .Vb 3 \& Warning: Updating the firmware can render the device driver and/or \& management tools incompatible. Before you update the firmware, \& it is recommended that you: .Ve .PP .Vb 1 \& 1) Back up your data. .Ve .PP .Vb 2 \& 2) Make sure you have a copy of the current firmware image so that \& you can roll back, if necessary. .Ve .PP .Vb 1 \& 3) Close all applications. .Ve .PP .Vb 1 \& Examining compatibility data from firmware image and /c2 ... Done. .Ve .PP .Vb 3 \& 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 .Ve .PP .Vb 2 \& Current firmware version is the same as the new firmware. \& Recommendation: No need to update. .Ve .PP .Vb 4 \& 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. .Ve .PP The \fBforce\fR 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. .RE .IP "\fI/cx\fR \fBshow\fR \fIevents\fR [\fIreverse\fR]" .IX Item "/cx show events [reverse]" .RE .PD 0 .IP "\fI/cx\fR \fBshow\fR \fIAENs\fR [\fIreverse\fR]" .IX Item "/cx show AENs [reverse]" .RE .IP "\fI/cx\fR \fBshow\fR \fIalarms\fR [\fIreverse\fR]" .IX Item "/cx show alarms [reverse]" .PD 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 \s-1CLI\s0 and/or 3DM2. These events reflect messages of varying severity levels. The levels range in order of severity: \s-1INFO\s0, \s-1WARNING\s0, and \s-1ERROR\s0, respectively. .PP 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 \*(L"Date\*(R" column. Also, with the 7000/8000 series controllers, the event message contains the severity as well, hence the \*(L"Severity\*(R" column shows a '\-' also. .PP 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 \fIreverse\fR. With this the most recent \s-1AEN\s0 message would appear at the top of the table. .PP Typical output looks like: .PP .Vb 1 \& //localhost> /c1 show events .Ve .PP .Vb 12 \& 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 .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIdiag\fR" .IX Item "/cx show diag" This command extracts controller diagnostic information as output for technical support usage and reference. The report contains a summary of the controller's technical information (such as host name, host architecture, operating system version, controller model, controller \s-1ID\s0, etc.), followed by diagnostic information of the controller. .PP A small section showing event trigger and log information is shown for controller models 9650SE or higher with release 9.5.3 or higher firmware. This section shows the diagnostic event log save mode type with three diagnostic event counters. These diagnostic events are controller soft reset, firmware reset, and drive error. .PP For controller models 9550SX and older, or firmware version of release 9.5.2 or older, the diagnostic trigger and log section is either not shown or indicates 'N/A' for the mode and counter values. .PP Typical output (for model 9650SE/higher and running 9.5.3/higher release) looks like the following: .PP .Vb 1 \& //dhcp-147-145-95-103> /c2 show diag .Ve .PP .Vb 13 \& ### Time Stamp: 18:51:11 31-May-2011 \& ### Host Name: dhcp-147-145-95-103 \& ### Host Architecture: x86_64 (64 bit) \& ### OS Version: Linux 2.6.11-1.1369_FC4smp \& ### Model: G133e/AstorElx \& ### Serial #: 3ware Internal Use \& ### Controller ID: 2 \& ### CLI Version: 2.00.11.018 \& ### API Version: 2.08.00.022 \& ### Driver Version: 2.26.06.001 \& ### Firmware Version: FH9X 4.10.00.001 \& ### BIOS Version: BE9X 4.08.00.002 \& ### Available Memory: 448MB .Ve .PP .Vb 14 \& ========================================================================== \& Diagnostic Information on Controller //dhcp-147-145-95-103/c2 ... \& -------------------------------------------------------------------------- \& Event Trigger and Log Information: \& Triggered Event(s) = \& ctlreset (controller soft reset) \& fwassert (firmware assert) \& driveerr (drive error) \& Diagnostic log save mode = cont (continuous/last trigger) \& Diagnostic event trigger counter = 1 \& Trigger event counter for ctlrreset = 0 \& Trigger event counter for fwassert = 0 \& Trigger event counter for driveerr = 5 \& -------------------------------------------------------------------------- .Ve .PP .Vb 35 \& SAS Amp|Pre[0] 0x0500|26 \& SATA Amp|Pre[0] 0x0400|26 \& RxDetectionThreshold[0] = 0xd2 \& SAS Amp|Pre[1] 0x0500|26 \& SATA Amp|Pre[1] 0x0400|26 \& RxDetectionThreshold[1] = 0xd2 \& EPCT file not found in flash. \& Auto detecting enclosures ... \& Rollcall, Begin : find drives \& Inventory done, port=0 \& Inventory done, port=2 \& Inventory done, port=1 \& Assigning drive handle 6 to port 0 \& Assigning drive handle 2 to port 1 \& Assigning drive handle 3 to port 2 \& Associate slots: Rollcall, Waiting to start DCB read \& --PortHandle[ 0] DriveHandle[ 6] phy: 6 \& DIT status: DRV_PRESENT (0xFF) \& Drv type: SSP Direct \& Model #: SEAGATE ST31000640SS \& Serial #: 9QJ2NN8Q \& Drv FW #: 0004 \& Capacity: 1953525167 (0x0000000074706DAF) (~931 GB) \& drv ports: Supported 2, Connected : 1 \& WWN: 5000c5000d32ee9c \& sasAddr1: 5000c5000d32ee9d \& sasAddr2: 5000c5000d32ee9e \& WriteSame: 1 \& Pwr On Hrs: 12760, Realloc Sct: 12, Temp (\euffffC): 23 \& Link Speed: Supported=0x3 (1.5 Gbs to 3.0 Gbs) Current=0x2 (3.0 Gbs) \& Spndle Spd: 7200 \& : \& : \& : \& : .Ve .PP It is recommended that you save the output to a file, where it can be used to communicate with tech support, or used for further analysis with Linux utilities like \fIod\fR\|(1). .PP Example: .PP .Vb 1 \& $ tw_cli /c0 show diag > diag.txt .Ve .PP Please note that some characters may not be printable or may not render correctly. .RE .IP "\fI/cx\fR \fBshow\fR \fIphy\fR" .IX Item "/cx show phy" 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 \s-1SATA\s0 or \s-1SAS\s0. The \&'Device' column is the device \s-1ID\s0 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. .PP looks like the following Example of 9690SA\-8E connected to drives in an enclosure: .PP .Vb 12 \& //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 .Ve .PP 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. .PP Example of 9690SA\-8I with directly attached drives: .PP .Vb 1 \& //localhost> /c3 show phy .Ve .PP .Vb 11 \& 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 - - - - - - .Ve .PP \&\fBNote:\fR There is no \*(L"/cx set phy\*(R" command. Moreover, the only changeable setting for phy is link speed. To change the link speed, see the \&\fI/cx/phyx set link\fR command. To see information for an individual phy only, use \fI/cx/phyx show\fR. These commands are in the \*(L"Phy Object Messages\*(R" section. .RE .IP "\fI/cx\fR \fBshow\fR \fIrebuild\fR" .IX Item "/cx show rebuild" 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 \fIadd\fR, \fIdel\fR, \fIshow\fR and \fIset\fR. Background tasks have a slot id, start day, hour, duration, and status attributes. .PP Rebuild activity attempts to (re)synchronize all members of redundant units such as \s-1RAID\-1\s0, \s-1RAID\-10\s0, \s-1RAID\-5\s0 and \s-1RAID\-50\s0. Rebuilds can be started manually or automatically if a spare has been defined. Scheduled rebuilds will take place during the scheduled window, if enabled. .PP This command displays the current rebuild background task schedule as illustrated below. .PP .Vb 1 \& $ tw_cli /c1 show rebuild .Ve .PP .Vb 11 \& 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 .Ve .PP The status of \fIdisabled\fR denotes that the controller will not use the scheduled time slots. .RE .IP "\fI/cx\fR \fBshow\fR \fIrebuildmode\fR" .IX Item "/cx show rebuildmode" This command shows the current rebuild mode setting of the specified controller. The rebuild mode has two settings: \*(L"Adaptive\*(R" and \*(L"Low latency\*(R". .PP The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting \*(L"throttles\*(R" 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). .PP This command is associated with the rebuild task rate, please also see /cx show rebuildrate. .PP This command is supported on the 9650SE controller with Release 9.5.2 or later and for the 9690SA and higher model controllers. .PP Example: .PP .Vb 2 \& //localhost> /c1 show rebuildmode \& /c1 Rebuild background task mode = Low Latency .Ve .PP See also: .PP .Vb 3 \& /cx set rebuildmode= \& /cx set rebuildrate=<1..5> \& /cx show rebuildrate .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIrebuildrate\fR" .IX Item "/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. .PP This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows: .PP .Vb 5 \& 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 .Ve .PP This command applies to the 7000, 8000, and 9000 models controllers. .PP For example: .PP .Vb 2 \& //localhost> /c1 show rebuildrate \& /c1 Rebuild background task rate = 4 (faster rebuild; slower I/O) .Ve .PP See also: .PP .Vb 3 \& /cx set rebuildrate=<1..5> \& /cx set rebuildmode= \& /cx show rebuildmode .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIverify\fR" .IX Item "/cx show verify" Verify is one of the supported background tasks, and this command displays the current verify schedule. .PP For the 9650SE and newer \s-1RAID\s0 controllers, the Verify Task Schedule can be either \&\fBbasic\fR or \fBadvanced\fR (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 \s-1RAID\s0 controllers. .PP 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 \fIadd\fR, \fIdel\fR, \fIshow\fR and \fIset\fR. The task schedule has a slot id, start\-day\-time, duration, and status attributes. Rebuild follow similar background task schedules. .PP For details about setting up a schedule for verify tasks, see \fI/cx set verify\fR. .PP Verify activity attempts to verify all units based on their unit type. Verifying \&\s-1RAID\-1\s0 involves checking that both drives contain the exact data. On \s-1RAID\-5\s0 and \&\s-1RAID\-6\s0, the parity information is used to verify data integrity. \s-1RAID\-10\s0 and 50 are composite types and follow their respective array types. On the 9000 series, non-redundant units such as \s-1RAID\-0\s0, \s-1JBOD\s0, single, and spare, are also verified (by reading and reporting un-readable sectors). .PP 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. .PP .Vb 1 \& $ tw_cli /c1 show verify .Ve .PP .Vb 11 \& 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 .Ve .PP The status of \fIdisabled\fR denotes that the controller will not use the scheduled time slots. .PP Example 2: For the 9650SE and newer controllers, if the \fBbasic\fR Verify Task Schedule is selected, the show verify command displays the following: .PP .Vb 2 \& //localhost> /c1 show verify \& /c1 basic verify weekly preferred start: Friday 12:00am .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIverifymode\fR" .IX Item "/cx show verifymode" This command shows the current verify mode setting of the specified controller. The verify mode has two settings: \*(L"Adaptive\*(R" and \*(L"Low latency\*(R". .PP The Adaptive setting tells the controller to keep its current background activity task policy and it is the default. The Low Latency setting \*(L"throttles\*(R" 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). .PP This command is associated with the verify task rate, please also see /cx show verifyrate. .PP This command is supported on the 9650SE controller with Release 9.5.2 or higher, and for the 9690SA and higher model controllers. .PP Example: .PP .Vb 2 \& //localhost> /c1 show verifymode \& /c1 Verify background task mode = Low Latency .Ve .PP See also: .PP .Vb 3 \& /cx set verifymode= \& /cx set verifyrate=<1..5> \& /cx show verifyrate .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIverifyrate\fR" .IX Item "/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. .PP This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows: .PP .Vb 5 \& 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 .Ve .PP This command applies to the 7000, 8000, and 9000 models controllers. .PP For example: .PP .Vb 2 \& //localhost> /c1 show verifyrate \& /c1 Verify background task rate = 4 (faster rebuild; slower I/O) .Ve .PP See also: .PP .Vb 3 \& /cx set verifyrate=<1..5> \& /cx set verifymode= \& /cx show verifymode .Ve .RE .IP "\fI/cx\fR \fBshow\fR \fIselftest\fR" .IX Item "/cx show selftest" 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 \&\fIadd\fR, \fIdel\fR, \fIshow\fR and \fIset\fR a task. Background tasks have attributes of slot id, start\-day\-time, duration, and status. .PP The selftest that would be performed is called \s-1SMART\s0 (Self Monitoring Analysis and Reporting). The \s-1SMART\s0 selftest instructs the controller to check certain \s-1SMART\s0 supported thresholds by the disk vendor. An \s-1AEN\s0 is logged to the alarms table if a drive reports a \s-1SMART\s0 failure. The failing drive should be replaced if this error occurs. .PP This command displays the current selftest background task schedule as illustrated below. .PP .Vb 1 \& $ tw_cli /c1 show selftest .Ve .PP .Vb 11 \& 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 .Ve .RE .IP "\fI/cx\fR \fBadd\fR \fIrebuild=ddd:hh:duration\fR" .IX Item "/cx add rebuild=ddd:hh:duration" This command registers a new background rebuild task to the schedule, for execution on the day of \fIddd\fR (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at the hour of \fIhh\fR (range 0 .. 23), for a duration of \fIduration\fR (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. .PP For \*(L"rebuild\*(R" background task description, see command \fB/cx show rebuild\fR. .PP For example: .PP .Vb 2 \& //localhost> /c3 add rebuild=sun:16:3 \& Adding scheduled rebuild to slot 7 for [Sun, 4:00PM, 3hr(s)] ... Done. .Ve .RE .IP "\fI/cx\fR \fBadd\fR \fIverify=ddd:hh:duration\fR" .IX Item "/cx add verify=ddd:hh:duration" This command registers a new task slot to the Verify Task Schedule on the day of \fIddd\fR (where \fIddd\fR is Sun, Mon, Tue, Wed, Fri, or Sat), at the hour of \fIhh\fR (range 0..23), for a duration of \fIduration\fR (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. .PP \&\fBNote:\fR 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'. .PP \&\fBNote:\fR If you have a 9650SE with Release 9.5.2 or later, or a 9690SA or newer controller, you may use the simpler \fBbasic\fR verify schedule with the command \&\fI/cx set verify=basic\fR. Simply specify a weekly day and time and make sure that the auto-verify policy is set to \s-1ON\s0 for your \s-1RAID\s0 units. For more information please see '/cx set verify=basic' or the section on Basic Verify in the Features section of this document. .PP Example: .PP .Vb 2 \& //localhost> /c3 add verify=sun:23:2 \& Adding scheduled verify to slot 3 for [Sun, 11:00PM, 2hr(s)] ... Done. .Ve .PP 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 \s-1PM\s0. .PP \&\fBNote:\fR Use the \fI/cx/ux set autoverify=on\fR command to turn on autoverify for each unit you wish to follow the schedule. .RE .IP "\fI/cx\fR \fBadd\fR \fIselftest=ddd:hh\fR" .IX Item "/cx add selftest=ddd:hh" This command registers a new background \fIselftest\fR task to the schedule, for executed on day of \fIddd\fR (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at hour of \fIhh\fR (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. .PP For \*(L"selftest\*(R" background task description, see command \fB/cx show selftest\fR. .PP Example: .PP .Vb 2 \& //localhost> /c1 add selftest=Sun:16 \& Adding scheduled verify to slot 7 for [Sun, 4:00PM] ... Done. .Ve .RE .IP "\fI/cx\fR \fBdel\fR \fIrebuild=slot_id\fR" .IX Item "/cx del rebuild=slot_id" This command will remove (or unregister) the rebuild background task in slot \fIslot_id\fR. .PP For \*(L"rebuild\*(R" background task description, see command \fB/cx show rebuild\fR. .PP Example: .PP .Vb 2 \& $ tw_cli /c1 del rebuild=2 \& Removing scheduled rebuild slot [2] ... Done. .Ve .PP \&\s-1WARNING:\s0 If all timeslots are removed, be sure to also disable the schedule. Otherwise, no firmware initiated or manually started rebuild tasks would run. .RE .IP "\fI/cx\fR \fBdel\fR \fIverify=slot_id\fR" .IX Item "/cx del verify=slot_id" This command will remove (or unregister) the verify background task in slot \fIslot_id\fR. .PP For \*(L"verify\*(R" background task description, see command \fB/cx show verify\fR. .PP Example: .PP .Vb 2 \& $ tw_cli /c1 del verify=3 \& Removing scheduled verify slot [3] ... Done. .Ve .PP \&\s-1WARNING:\s0 If all timeslots are removed, be sure to also disable the schedule. Otherwise, no firmware initiated or manually started verify tasks would run. .RE .IP "\fI/cx\fR \fBdel\fR \fIselftest=slot_id\fR" .IX Item "/cx del selftest=slot_id" This command will remove (or unregister) the selftest background task in slot \fIslot_id\fR. .PP For \*(L"selftest\*(R" background task description, see command \fB/cx show selftest\fR. .PP Example: .PP .Vb 2 \& $ tw_cli /c1 del selftest=3 \& Removing scheduled selftest slot [3] ... Done. .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIrebuild=" .IX Item "/cx set rebuild=" This command will \fIenable\fR or \fIdisable\fR all of the scheduled rebuild background tasks on controller \fI/cx\fR. When enabled, only registered or scheduled tasks will execute. Any previous on-demand (manually started) background tasks will be ignored. .PP 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: .PP .Vb 5 \& 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 .Ve .PP This command applies to 7000, 8000, and 9000 models controllers. For 7/8000 series, the rebuild rate also applies to verify and mediascan tasks. .PP For \*(L"rebuild\*(R" background task description, see command \fB/cx show rebuild\fR. .RE .IP "\fI/cx\fR \fBset\fR \fIrebuildmode=" .IX Item "/cx set rebuildmode=" 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 \*(L"throttle\*(R" the background task and allow host Reads to complete, thus improving performance. .PP The rebuild mode has two settings: \*(L"Adaptive\*(R" and \*(L"Low latency\*(R". 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. .PP This command is associated with the rebuild task rate, please also see /cx set rebuildrate. .PP This command is supported on the 9650SE controller with Release 9.5.2 or later, and for the 9690SA and higher model controllers. .PP \&\fBNote:\fR 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. .PP Example: .PP .Vb 2 \& //localhost> /c1 set rebuildmode=lowlatency \& Setting Rebuild background task mode on /c1 to [lowlatency] ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show rebuildmode \& /cx set rebuildrate=<1..5> \& /cx show rebuildrate .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIrebuildrate=<1..5\fR>" .IX Item "/cx set rebuildrate=<1..5>" The execution priority relative to I/O operations for the rebuild background task is the rebuild task rate. The rebuild task rate set to \*(L"fastest\*(R" will consume all of the controller's resources and will correspondingly deter I/O operations. Accordingly, the converse is also true. .PP This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows: .PP .Vb 5 \& 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 .Ve .PP This command applies to the 7000, 8000, and 9000 models controllers. .PP Example: .PP .Vb 2 \& //localhost> /c1 set rebuildrate=2 \& Setting Rebuild background task rate on /c1 to [2] (faster I/O) ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show rebuildrate \& /cx set rebuildmode= \& /cx show rebuildmode .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIverify=" .IX Item "/cx set verify=" This command will \fIenable\fR or \fIdisable\fR all of the scheduled verify background tasks on controller \fI/cx\fR. When enabled, only registered or scheduled tasks will execute. Any previous on-demand (manually started) background tasks will be ignored. .PP 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: .PP .Vb 5 \& 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 .Ve .PP Note that this feature only applies to 9000 and higher controller models. .PP For \*(L"verify\*(R" background task description, see command \fB/cx show verify\fR. .PP \&\fBNote:\fR 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.) .PP \&\fBNote:\fR 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'. .RE .IP "\fI/cx\fR \fBset\fR \fIverify=" .IX Item "/cx set verify=" This command only applies to controller models 9750, 9690SA and 9650SE with Release 9.5.2 or later. .PP This command is effectively the same as the 'set verify' command. Setting verify to \fIadvanced\fR enables the Verify Tasks Schedule, which can include a series of up to 7 days and times. Setting \fIverify\fR to \&\fIbasic\fR creates a weekly schedule with one specific day and time, and disables the series of scheduling slots associated with the advanced verify task schedule. .RE .IP "\fI/cx\fR \fBset\fR \fIverify=" .IX Item "/cx set verify=" This command only applies to 9650SE and higher model controllers. .PP 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. .PP When you set verify=basic, the table of scheduled time slots associated with the advanced Verify Task Schedule is ignored. .PP Verify=basic is intended to be used with the auto-verify policy for \s-1RAID\s0 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 \s-1ON\s0 by default. .PP \&\fBNote:\fR 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 \&\fI/cx/ux start verify\fR. .PP For example: .PP .Vb 2 \& //localhost> /c3 set verify=basic pref=Fri:23 \& Setting /c3 basic verify preferred start time to [Fri, 11:00PM] ... Done. .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIverifymode=" .IX Item "/cx set verifymode=" 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 \*(L"throttle\*(R" the background task and allow host Reads to complete, thus improving performance. .PP The verify mode has two settings: \*(L"Adaptive\*(R" and \*(L"Low latency\*(R". 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. .PP This command is associated with the verify task rate, please also see \&\fI/cx set verifyrate\fR. .PP This command is supported on the 9650SE controller with Release 9.5.2 or later and for the 9690SA and higher model controllers. .PP \&\fBNote:\fR 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. .PP Example: .PP .Vb 2 \& //localhost> /c1 set verifymode=lowlatency \& Setting Verify background task mode on /c1 to [lowlatency] ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show verifymode \& /cx set verifyrate=<1..5> \& /cx show verifyrate .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIverifyrate=<1..5\fR>" .IX Item "/cx set verifyrate=<1..5>" The execution priority relative to I/O operations for the verify background task is the verify task rate. The verify task rate set to \*(L"fastest\*(R" 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. .PP This task rate is of the range [1..5], where 5 denotes the setting of fastest background task and slowest I/O, as follows: .PP .Vb 5 \& 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 .Ve .PP This command applies to the 7000, 8000, and 9000 models controllers. .PP Example: .PP .Vb 2 \& //localhost> /c1 set verifyrate=2 \& Setting Verify background task rate on /c1 to [2] (faster I/O) ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show verifyrate \& /cx set verifymode= \& /cx show verifymode .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIselftest=enable|disable\fR" .IX Item "/cx set selftest=enable|disable" This command will \fIenable\fR or \fIdisable\fR the \s-1SMART\s0 selftest task on on the specified controller \fI/cx\fR. When enabled, the selftest task will be performed during a scheduled timeslot. .PP For \*(L"selftest\*(R" background task description, see command \fI/cx show selftest\fR. .PP Example: .PP .Vb 2 \& //localhost>>/c2 set selftest=enable \& Sending commands to enable all selftests ... Done. .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIondegrade=cacheoff|follow\fR (9500S only)" .IX Item "/cx set ondegrade=cacheoff|follow (9500S only)" This command allows you to set a controller based write cache policy. If the policy is set to \fIcacheoff\fR, 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 \fIfollow\fR, then if a unit is degraded, firmware will follow whatever policy has been set for that unit. .RE .IP "\fI/cx\fR \fBset\fR \fIspinup=nn\fR" .IX Item "/cx set spinup=nn" 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. .PP Example: .PP .Vb 2 \& //localhost>>/c2 set spinup=2 \& Setting Disk Spinup Policy on /c2 to [2] ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show spinup \& /cx set stagger=nn \& /cx show stagger .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIstagger=nn\fR" .IX Item "/cx set stagger=nn" 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. .PP Example: .PP .Vb 2 \& //localhost>>/c2 set stagger=3 \& Setting Spinup Stagger Time Policy on /c2 to [3] ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show stagger \& /cx set spinup=nn \& /cx show spinup .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIdpmstat= (9550SX and higher)" .IX Item "/cx set dpmstat= (9550SX and higher)" This command allows you to enable or disable the Drive Performance Monitor (\s-1DPM\s0). By setting \fBdpmstat\fR to \fIon\fR you can enable the gathering of statistics for drives when I/O is running. These statistics can be helpful when troublshooting performance problems. .PP You can see whether the Perfromance Monitor is currently running and dispaly a statistic summary by using the command \fI/cx show dpmstat\fR. .PP The \s-1DPM\s0 is disabled by default since there is overhead in maintaining the statistics, and would be disabled following a reboot or power\-on. .PP Note that turning off \s-1DPM\s0 does not clear the statistical data that has been recorded. To clear the data, use the command \fI/cx/px set dpmstat=clear\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0 set dpmstat=off \& Setting Drive Performance Monitoring on /c0 to [off]... Done. .Ve .PP For more information regarding the \s-1DPM\s0 and statistics gathered, please see the section on 'Drive Performance Monitor' of the Features section, or the \&\*(L"\s-1SATA\s0 \s-1RAID\s0 Sofware User Guide, Version 9.5.1\*(R" in 3ware \s-1SAS\s0. .RE .IP "\fI/cx\fR \fBset\fR \fIautocarve= (9550SX and higher)" .IX Item "/cx set autocarve= (9550SX and higher)" This command allows you to set the Auto-Carving policy to be on or off. When the Auto-Carving policy is \s-1ON\s0, 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 \s-1TB\s0. This feature is useful for operating systems limited to 2 \s-1TB\s0 filesystems. .PP For example a 3 \s-1TB\s0 array would be configured into a 2 \s-1TB\s0 and a 1 \s-1TB\s0 volumes with default carvesize. For a 5 \s-1TB\s0 array, two 2 \s-1TB\s0 volumes would be created plus a 1 \s-1TB\s0 volume. .PP When autocarve policy is off, all the new unit creation or migration consists of one single volume. .PP Example: .PP .Vb 2 \& //localhost> /c0 set autocarve=on \& Setting Auto-Carving Policy on /c0 to on ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show autocarve \& /cx set carvesize=<1024..32768> \& /cx show carvesize` .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIcarvesize=<1024..32768\fR> (9550SX and higher)" .IX Item "/cx set carvesize=<1024..32768> (9550SX and higher)" This command allows you to set the carve size in \s-1GB\s0. This feature works together with the autocarve above. See "\fI/cx\fR \fBset\fR \fIautocarve=on|off\fR" command above for details. .PP Example: .PP .Vb 2 \& //localhost> /c0 set carvesize=2000 \& Setting Auto-Carving Size on /c0 to 2000 GB ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx show carvesize` \& /cx set autocarve= \& /cx show autocarve .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIautorebuild= (9550SX and higher)" .IX Item "/cx set autorebuild= (9550SX and higher)" This command sets the Auto-Rebuild policy of the specified controller to be \s-1ON\s0 or \s-1OFF\s0. If there is a degraded unit and the policy is set to \s-1ON\s0, the controller firmware will choose drives in the following order of priority, for a candidate to perform the rebuild operation: .PP 1. Smallest usable capacity spare. .PP 2. Smallest usable unconfigured drive. .PP 3. Smallest usable capacity failed drive. .PP If the policy is \s-1OFF\s0, spares are the only candidate for the rebuild operation. .PP Example: .PP .Vb 2 \& //localhost> /c0 set autorebuild=on \& Setting Auto-Rebuild Policy on /c0 to on ... Done. .Ve .PP See also: .PP .Vb 1 \& /cx show autorebuild .Ve .RE .IP "\fI/cx\fR \fBset\fR \fIautodetect= \fIdisk=\fR|[all] (9000 series)" .IX Item "/cx set autodetect= disk=|[all] (9000 series)" This command is associated with the stagger spin-up feature during hot\-plug. With stagger spin-up enabled (see command \fB/cx set spinup\fR and \fB/cx set stagger\fR), 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, \fBnot\fR 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. .PP The \fBautodetect=on|off\fR attribute configures the controller drive auto-detect setting. It should be set to \fIoff\fR 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 \fIon\fR to complete the configuration process for the controller to initiate the drive spin\-up. .PP The \fBdisk=\fR\fB\fB|all\fR 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 \fIoff\fR to initiate stagger spin-up during hot\-plug, where \fIport 3\fR was empty and \&\fIports 5\fR and \fI6\fR had drives inserted. .PP .Vb 2 \& //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 .Ve .PP If \*(L"disk=all\*(R", then all of the drives or ports for that controller are specified. for example: .PP .Vb 2 \& //localhost>> /c0 set autodetect=off disk=all \& Setting Auto-Detect on /c2 to [off] for all disks/ports... Done. .Ve .PP To illustrate how the command is used, here is a usage scenario: .PP .Vb 6 \& 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. .Ve .PP 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. .RE .IP "\fI/cx\fR \fBstart\fR \fImediascan\fR (7000/8000 only)" .IX Item "/cx start mediascan (7000/8000 only)" The commands starts a media scan operation on the specified controller \fI/cx\fR. 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. .RE .IP "\fI/cx\fR \fBstop\fR \fImediascan\fR (7000/8000 only)" .IX Item "/cx stop mediascan (7000/8000 only)" The commands stops a media scan operation on the specified controller \fI/cx\fR. 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. .Sh "Logical Disk Object Messages" .IX Subsection "Logical Disk Object Messages" 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 \fI/c0/u0\fR. .PP Note that in the output of unit information tables that follows, the column \&\*(L"Port\*(R" may be \*(L"VPort\*(R" depending on the applicable controller. .RE .IP "\fI/cx/ux\fR \fBshow\fR" .IX Item "/cx/ux show" This command shows summary information on the specified unit \fI/cx/ux\fR. If the unit consists of sub-units as with \s-1RAID\-10\s0 and \s-1RAID\-50\s0 arrays, then each sub-unit is further presented. If the Auto-Carving policy was \s-1ON\s0 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. .PP The following example shows a \s-1RAID\-50\s0 (u0) and a \s-1RAID\-0\s0 (u1) array, respectively: .PP .Vb 1 \& //localhost> /c0/u0 show .Ve .PP .Vb 11 \& 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 .Ve .PP .Vb 1 \& //localhost> /c0/u1 show .Ve .PP .Vb 17 \& 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 .Ve .PP 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. .PP The unit information table shows the percentage completion of the processes associated with the unit with \fB%RCompl\fR (percent Rebuild completion) and \fB%V/I/M\fR (percent Verifying, Initializing, or Migrating). .PP Unlike other array types, \s-1RAID\-6\s0 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 \f(CW%RCompl\fR and \f(CW%V\fR/I/M, and these are (A) and (P). \&\fB(A)\fR denotes that the percentage completion is for the current active process, and \fB(P)\fR denotes that the percentage completion is for the current paused process. For example: .PP .Vb 1 \& /localhost> /c0 show unitstatus .Ve .PP .Vb 3 \& 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 .Ve .PP Here, the \s-1RAID\-6\s0 unit \fIu0\fR 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. .PP For the unit display: .PP .Vb 1 \& //localhost> /c0/u0 show .Ve .PP .Vb 15 \& 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 .Ve .PP In the above example, the \s-1RAID\-6\s0 unit \fIu0\fR has 3 parity drives. Currently, it has two \s-1REBUILDING\s0 drives; one is in the active rebuilding state and another is in the paused rebuild state. The unit is also in the paused \&\s-1VERIFY\s0 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. .RE .IP "\fI/cx/ux\fR \fBshow\fR Attribute Attribute ..." .IX Item "/cx/ux show Attribute Attribute ..." This command shows the current setting of the given \fIattribute(s)\fR. 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. .PP 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 \s-1RAID\-6\s0 array; and the rdcache attribute is applicable for the 9650SE (with Release 9.5.2 or later) and newer controllers. .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIstatus\fR" .IX Item "/cx/ux show status" This command reports the status of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show status \& /c0/u5 status = OK .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIrebuildstatus\fR" .IX Item "/cx/ux show rebuildstatus" This command reports the rebuildstatus (if any) of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show rebuildstatus \& /c0/u5 is not rebuilding, its current state is OK .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIverifystatus\fR" .IX Item "/cx/ux show verifystatus" This command reports the verifystatus (if any) of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show verifystatus \& /c0/u5 is not verifying, its current state is OK .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIinitializestatus\fR" .IX Item "/cx/ux show initializestatus" This command reports the initializestatus (if any) of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show initializestatus \& /c0/u5 is not initializing, its current state is OK .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIvolumes\fR (9000 series)" .IX Item "/cx/ux show volumes (9000 series)" This command reports the number of volumes in the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show volumes \& /c0/u5 Volume(s) = 2 .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIname\fR (9000 series)" .IX Item "/cx/ux show name (9000 series)" This command reports the name (if any) of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show name \& /c0/u5 Name = Joe .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIserial\fR (9000 series)" .IX Item "/cx/ux show serial (9000 series)" This command reports the unique serial number of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show serial \& /c0/u5 Serial Number = 12345678901234567890 .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIqpolicy\fR (9550SX and higher)" .IX Item "/cx/ux show qpolicy (9550SX and higher)" This command reports the queue policy of the specified unit. If the queue policy is \s-1ON\s0, 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. .PP 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 \*(L"new\*(R" unit. Thus, this commmand does not show the queue policy for the spare unit type. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show qpolicy \& /c0/u5 Command Queuing Policy = on .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIstorsave\fR (9550SX and higher)" .IX Item "/cx/ux show storsave (9550SX and higher)" This command reports the storsave policy (protect|balance|perform) of the specified unit. .PP For detail, see \fI/cx/ux\fR \fIset\fR \fIstorsave=protect|balance|perform\fR. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 show storsave \& /c0/u5 Command Storsave Policy = protect .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIidentify\fR (9550SX and higher)" .IX Item "/cx/ux show identify (9550SX and higher)" This command reports the identify status of the specified unit within an enclosure. If set to \s-1ON\s0, the LEDs of the drive slots associated with the specified unit would blink. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show identify \& /c0/u0 Identify status = on. .Ve .PP See also: .PP .Vb 3 \& /cx/ux set identify= \& /cx/px set identify= \& /cx/px show identify .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIautoverify\fR (9000 series)" .IX Item "/cx/ux show autoverify (9000 series)" This command reports the current autoverify setting of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show autoverify \& /c0/u0 Auto Verify Policy = off .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIcache\fR" .IX Item "/cx/ux show cache" .RE .PD 0 .IP "\fI/cx/ux\fR \fBshow\fR \fIwrcache\fR" .IX Item "/cx/ux show wrcache" .PD This command reports the current write cache state of the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show cache \& /c0/u0 Write Cache = on .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIrdcache\fR" .IX Item "/cx/ux show rdcache" This command reports the current read cache setting of the specified unit. The state of the read cache could be either \fBbasic\fR, \fBintelligent\fR, or \&\fBoff\fR. \*(L"Off\*(R" denotes that the read cache is disabled. For more information on the read cache modes of Basic and Intelligent, please see \fI/cx/ux set rdcache\fR. .PP 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. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show rdcache \& /c0/u0 Read Cache = Intelligent .Ve .PP See also: .PP .Vb 1 \& /cx/ux set rdcache= .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIignoreECC\fR (9000 series)" .IX Item "/cx/ux show ignoreECC (9000 series)" This command reports the current setting of the ignoreECC policy for the specified unit. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 show ignoreECC \& /c0/u0 Ignore ECC policy = off .Ve .RE .IP "\fI/cx/ux\fR \fBshow\fR \fIrapidrecovery\fR (9650SE and higher)" .IX Item "/cx/ux show rapidrecovery (9650SE and higher)" This command shows the Rapid \s-1RAID\s0 Recovery policy for the specified unit. This policy can be \fIall\fR, \fIrebuild\fR, or \fIdisable\fR. For more information about the policy settings, please see \fI/cx/ux set rapidrecovery=. .PP This command only applies to the 9650SE (with Release 9.5.1) and newer controllers, as well as redundant arrays only. .PP For example: .PP .Vb 2 \& //localhost> /c0/u0 show rapidrecovery \& /c1/u0 Rapid RAID Recovery policy setting = disable .Ve .PP \&\fBNote:\fR The attribute \fIrapidrecovery\fR in the command may be abbreviated as \*(L"rrr\*(R". .RE .IP "\fI/cx/ux\fR \fBshow all\fR" .IX Item "/cx/ux show all" This command shows the current setting of all of the above attributes. .PP 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 \s-1TB\s0 \- 1), multiple volumes will be created and will be displayed at the end of the summary information. .PP Example: .PP .Vb 1 \& //localhost> /c0/u1 show all .Ve .PP .Vb 7 \& /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 .Ve .PP .Vb 1 \& //localhost> /c0/u1 show .Ve .PP .Vb 17 \& 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 .Ve .RE .IP "\fI/cx/ux\fR \fBremove\fR [\fInoscan\fR] [\fIquiet\fR]" .IX Item "/cx/ux remove [noscan] [quiet]" This command allows you to remove (or export) a \fBunit\fR. Exporting a unit will instruct the firmware to remove the specified unit from its pool of managed units, but retains the \s-1DCB\s0 (Disk Configuration Block) meta\-data. As such the unit can later be imported back. \fInoscan\fR is used to not inform the \s-1OS\s0 of this change. Default is to inform the \s-1OS\s0. The quiet option is for non-interactive mode. .PP Use caution when using this command. Units that are currently in use or mounted cannot be removed. .RE .IP "\fI/cx/ux\fR \fBdel\fR [\fInoscan\fR] [\fIquiet\fR]" .IX Item "/cx/ux del [noscan] [quiet]" This command allows you to delete a \fBunit\fR. Deleting a unit not only remove the specified unit from the controller's list of managed units, but also \fBdestroys\fR the \s-1DCB\s0 (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 \fBcan not be recovered\fR. \&\fInoscan\fR is used to not inform the \s-1OS\s0 of this change. Default is to inform the \s-1OS\s0. The quiet option is for non-interactive mode. .PP Use caution when using this command. \fBThis is a destructive command and should be\fR \&\fBused with extreme care\fR. Units that are currently in use or mounted should not be deleted. .RE .IP "\fI/cx/ux\fR \fBstart\fR \fIrebuild\fR \fIdisk=p\fR [\fIignoreECC\fR]" .IX Item "/cx/ux start rebuild disk=p [ignoreECC]" This command allows you to rebuild a \s-1DEGRADED\s0 unit by using the specified \fBdisk=p\fR. Rebuild only applies to redundant arrays such as \s-1RAID\-1\s0, \s-1RAID\-5\s0, \s-1RAID\-10\s0 and \s-1RAID\-50\s0. During rebuild, bad sectors on the source disk will cause the rebuild to fail. You can allow for the operation to continue via \fBignoreECC\fR. Rebuild process is a background task and will change the state of a unit to \s-1REBUILDING\s0. Various \&\fBshow\fR commands also show a percent completion as rebuilding progresses. .PP Note that the disk to be used to rebuild a unit, must be a \s-1SPARE\s0 or unconfigured disk. .RE .IP "\fI/cx/ux\fR \fBstart\fR \fIverify\fR" .IX Item "/cx/ux start verify" This command starts a background verification process on the specified unit \fI/cx/ux\fR. 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. .PP .Vb 10 \& 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 | | | | | | | | | | \& --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ .Ve .PP 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. .PP 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. .RE .IP "\fI/cx/ux\fR \fBpause\fR \fIrebuild\fR" .IX Item "/cx/ux pause rebuild" This command allows you to \fBpause\fR the rebuild operation on the specified \&\s-1REBUILDING\s0 unit \fB/cx/ux\fR. 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. .PP Rebuild \fBpause\fR function is provided to enable 7000/8000 users to achieve functionality with use of \s-1OS\s0 provided schedulers such as \fIcron\fR\|(8) or, \fIat\fR\|(1) in Linux or user supplied programs. .RE .IP "\fI/cx/ux\fR \fBresume\fR \fIrebuild\fR" .IX Item "/cx/ux resume rebuild" This command allows you to \fBresume\fR the rebuild operation on the specified unit \fB/cx/ux\fR. 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. .PP Rebuild \fBresume\fR function is provided to enable 7000/8000 users to achieve similar functionality with use of \s-1OS\s0 provided schedulers such as \fIcron\fR\|(8) or, \fIat\fR\|(1) in Linux or user supplied programs. .RE .IP "\fI/cx/ux\fR \fBstop\fR \fIverify\fR" .IX Item "/cx/ux stop verify" This command stops a background verification process on the specified unit \fI/cx/ux\fR. 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. .PP .Vb 10 \& 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 | | | | | | | | | | \& --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ .Ve .PP 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. .RE .IP "\fI/cx/ux\fR \fBflush\fR" .IX Item "/cx/ux flush" This command allows you to flush the write cache on the specified unit \fI/ux\fR associated with controller \fI/cx\fR. Note that this command does not apply to spare unit types. .RE .IP "\fI/cx/ux\fR \fBset\fR \fIautoverify=" .IX Item "/cx/ux set autoverify=" This command allows you to turn on/off the autoverify operation on a specified unit \fI/cx/ux\fR. Once the autoverify=on, the \s-1RAID\s0 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. .PP You can use the \fBshow verify\fR 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 \*(L"/cx show verify\*(R" 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. .PP For a newly created unit on the 9650SE (with Release 9.5.1 or later), 9690SA, and 9750 controllers, autoverify is set to \s-1ON\s0 by default. For earlier controller models, the default is \s-1OFF\s0. .RE .IP "\fI/cx/ux\fR \fBset\fR \fIcache= [\fIquiet\fR]" .IX Item "/cx/ux set cache= [quiet]" .RE .PD 0 .IP "\fI/cx/ux\fR \fBset\fR \fIwrcache= [\fIquiet\fR]" .IX Item "/cx/ux set wrcache= [quiet]" .PD This command allows you to enable or disable the write cache on a specified unit \&\fI/cx/ux\fR. 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 \s-1BBU\s0 installed. The following is the Raid Type-Model support matrix. .PP .Vb 10 \& 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 | | | | | | | | | | \& --------+-------+-------+-------+-------+--------+--------+--------+------+-------+ .Ve .RE .IP "\fI/cx/ux\fR \fBset\fR \fIrdcache=" .IX Item "/cx/ux set rdcache=" This command allows you to set the read cache to either \fBbasic\fR, \&\fBintelligent\fR, or \fBoff\fR on a specified unit. .PP \&\fBRead Cache Basic\fR 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. .PP \&\fBRead Cache Intelligent\fR enables the Intelligent Read Prefetch (\s-1IRP\s0) 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 (\s-1IRP\s0) 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. .PP \&\fBNote:\fR If Intelligent mode is enabled, the features in Basic mode are also enabled. .PP The following table provides some recommendations for when to use each Read Cache setting. .PP .Vb 28 \& ------------------------------------------------------------------------ \& 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. | \& ------------------------------------------------------------------------ .Ve .PP 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. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 set rdcache=intelligent \& Setting Read Cache Policy on /c0/u0 to [intelligent] ... Done. .Ve .RE .IP "\fI/cx/ux\fR \fBset\fR \fIidentify= (9550SX and higher)" .IX Item "/cx/ux set identify= (9550SX and higher)" This command allows you to identify a unit within an enclosure. If set to \s-1ON\s0, the LEDs of the drive slots associated with the specified unit would blink. .PP Example: .PP .Vb 2 \& //localhost> /c0/u0 set identify=on \& Sending Identify request for unit /c0/u0 to [on] ... Done. .Ve .PP See also: .PP .Vb 3 \& /cx/ux show identify \& /cx/px show identify \& /cx/px set identify= .Ve .RE .IP "\fI/cx/ux\fR \fBset\fR \fIignoreECC= (9000 series)" .IX Item "/cx/ux set ignoreECC= (9000 series)" 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. .RE .IP "\fI/cx/ux\fR \fBset\fR \fIname=string\fR (9000 series)" .IX Item "/cx/ux set name=string (9000 series)" 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 \s-1OS\s0 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. .RE .IP "\fI/cx/ux\fR \fBset\fR \fIqpolicy= (9550SX and higher)" .IX Item "/cx/ux set qpolicy= (9550SX and higher)" 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. .PP 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 \*(L"new\*(R" unit. Thus, this commmand does not set the queue policy for the unit type spare. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 set qpolicy = on \& Setting Command Queuing Policy for unit /c0/u5 to [on] ... Done. .Ve .RE .IP "\fI/cx/ux\fR \fBset\fR \fIrapidrecovery= (9650SE and higher)" .IX Item "/cx/ux set rapidrecovery= (9650SE and higher)" .RE .PD 0 .IP "\fI/cx/ux\fR \fBset\fR \fIrapidrecovery= [\fIquiet\fR] (9650SE and higher)" .IX Item "/cx/ux set rapidrecovery= [quiet] (9650SE and higher)" .PD This command sets the Rapid \s-1RAID\s0 Recovery policy for the specified unit. Rapid \s-1RAID\s0 Recovery can speed up the rebuild process, and it can speed up the initialize and verify tasks for redundant arrays in the \s-1RAID\s0 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 \*(L"rapidrecovery\*(R" may be abbreviated as \&\*(L"rrr\*(R".) .PP \&\fBNote:\fR The default setting of Rapid \s-1RAID\s0 Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled. .PP \&\fBNote:\fR There is a quiet option for setting the Rapid \s-1RAID\s0 Recovery policy to disable. The quiet option is provided for scripting purposes and is applicable to the \fIdisable\fR setting only. .PP For example: .PP .Vb 2 \& //localhost> /c0/u0 set rapidrecovery=all \& Setting Rapid RAID Recovery policy on /c1/u0 to [all] ... Done. .Ve .PP \&\fBNote:\fR Rapid \s-1RAID\s0 Recovery is not supported over migration. .RE .IP "\fI/cx/ux\fR \fBset\fR \fIstorsave= [\fIquiet\fR] (9550SX and higher)" .IX Item "/cx/ux set storsave= [quiet] (9550SX and higher)" This command sets the storsave policy of the specified unit to be either protect, balance, or perform when the unit write cache is enabled. .PP 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 \&\fIprotect\fR mode is the default setting. .PP \&\fBprotect\fR \*(-- provides the maximum data protection among the controller settings. When user sets storsave to \fIprotect\fR, it means: .PP 1. \*(L"Write Cache\*(R" will be disabled when the unit becomes \*(L"\s-1DEGRADED\s0\*(R", .PP 2. all data flushing from controller cache will be flushed to media, and .PP 3. incoming \s-1FUA\s0 (Force Unit Access) host request will be ignored if a \s-1BBU\s0 is installed and enabled; Otherwise, will be honored. .PP \&\fBperform\fR \*(-- provides the maximum performance and less data protection among the controller settings. When user sets storsave to \fIperform\fR, it means: .PP 1. \*(L"Write Cache\*(R" will not be disabled when the unit becomes \*(L"\s-1DEGRADED\s0\*(R", .PP 2. all data flushing from controller cache will be flushed to disk, and .PP 3. incoming \s-1FUA\s0 (Force Unit Access) host request will be honored. .PP \&\fBNote:\fR When storsave is set to \fIperform\fR, 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 [\fIquiet\fR] option to bypass. .PP \&\fBbalance\fR \*(-- 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 \fIbalance\fR, it means: .PP 1. \*(L"Write Cache\*(R" will not be disabled when the unit becomes \*(L"\s-1DEGRADED\s0\*(R", .PP 2. all data flushing from controller cache will be flushed to media if a \&\s-1BBU\s0 is installed and enabled; Otherwise, will be flushed to disk only, and .PP 3. incoming \s-1FUA\s0 (Force Unit Access) host request will be ignored if a \s-1BBU\s0 is installed and enabled; Otherwise, will be honored. .PP Example: .PP .Vb 2 \& //localhost> /c0/u5 set storsave=protect \& Setting Command Storsave Policy for unit /c0/u5 to [protect] ... Done. .Ve .RE .IP "\fI/cx/ux\fR \fBmigrate\fR type=\fIRaidType\fR [disk=\fIp:\-p\fR] [group=\fI3|4|5|6|7|8|..|16\fR] [stripe=\fIStripe\fR] [\fInoscan\fR] [\fInocache\fR] [\fIautoverify\fR]" .IX Item "/cx/ux migrate type=RaidType [disk=p:-p] [group=3|4|5|6|7|8|..|16] [stripe=Stripe] [noscan] [nocache] [autoverify]" This feature is only available with 9000 series of controllers. .PP This command allows you to migrate an existing unit (aka source) to a unit with \&\fItype=RaidType\fR (aka destination), to increase capacity, change the \s-1RAID\s0 level (with the same or increased capacity), or change the stripe size. .PP 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 \fBdisk=\f(BIp:\-p\fB\fR disk list. Unspecified parameters are assigned default values (stripe size of 64K, write cache enabled, autoverify disabled, and ignoreECC disabled). .PP 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 \&\s-1RAID\-1\s0 and the destination unit is of type single, the disk-specifier of the migration command [disk=\fIp:\-p\fR] is actually not optional and must \fBnot\fR be included in the command. The drives in the \s-1RAID\-1\s0 array would become multiple units of type single after the migration, and the source drives are the destination drives. Specifying more drives with the \*(L"disk=\*(R" option would return an error. .PP Both source unit name and serial number will be carried over to the destination unit. However, the \s-1RAID\-1\s0 to single migration path is a special case. In this case, the \fBmigrate\fR 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 \fBnot\fR be carried over to new unit. The new destination unit will have its own serial number. .PP \&\fBtype=RaidType\fR consists of the destination unit \s-1RAID\s0 type as in \fBraid0\fR, \fBraid1\fR, \&\fBraid5\fR, \fBraid10\fR, \fBraid50\fR, \fBraid6\fR, or \fBsingle\fR. .PP For example \*(L"type=raid5\*(R" indicates the destination unit is \s-1RAID\-5\s0. .PP The following table illustrates valid migration paths: .PP .Vb 20 \& 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 | \& --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ .Ve .PP \&\fBNote:\fR You can only migrate a unit to a \s-1RAID\s0 level that has the same or larger capacity as the exisiting one. A four-drive \s-1RAID\-5\s0 unit can migrate to a four-drive \&\s-1RAID\-0\s0, but a four-drive \s-1RAID\-0\s0 unit cannot migrate to a four-drive \s-1RAID\-5\s0, without adding another drive, due to the need for additional storage capacity for parity bits. .PP \&\fBdisk=p:\-p\fR 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 \fB\*(L":\*(R"\fR or \fB\*(L"\-\*(R"\fR as port index separators. A dash indicates a range and can be mixed with \*(L":\*(R". For example \&\fBdisk=0:1:2\-5:9:12\fR indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12. .PP \&\fBgroup=3|4|5|6|7|8|9|10|11|12|13|14|15|16\fR is \fBonly\fR applicable to \fBtype=raid50\fR which consists of a number of disks per group. Recall that a \s-1RAID\-50\s0 is a multi-tier array. At the most bottom layer, N number of disks per group are used to form the \&\s-1RAID\-5\s0 layer. These \s-1RAID\-5\s0 arrays are then integrated into a \s-1RAID\-0\s0. This option allows you to specify the number of disks in the \s-1RAID\-5\s0 level. Valid values are 3, 4, 5 and 6. For example \fBgroup=3\fR indicates 3 disks of \s-1RAID\-5\s0 at the bottom layer of \s-1RAID\-50\s0. .PP \&\fBNote:\fR You can have a maximum of 4 subunits in a \s-1RAID\-50\s0 unit. .PP 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 \s-1RAID\-5\s0. However given 12 disks, specifying 3 will create four \s-1RAID\-5\s0 under the \s-1RAID\-0\s0 level. Given 6 disks and grouping of 6 is not allowed, as you'll basically be creating a \s-1RAID\-5\s0. .PP The default disk \fBgroup\fR 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. .PP Note that \s-1RAID\-10\s0 always has \fBgroup=2\fR, so an attribute specifying its group is not necessary. .PP \&\fBStripe\fR 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 \s-1KB\s0 (kilobytes). .PP .Vb 10 \& 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 | | | | \& ------+---------+-------+-------+-------+--------+--------+-------+-------+--------+ .Ve .PP \&\fBnoscan\fR instructs \s-1CLI\s0 not to notify the operating system (\s-1OS\s0) about the creation of the new unit. By default \s-1CLI\s0 will inform the \s-1OS\s0. One application of this feature is to prevent the \s-1OS\s0 from creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and a moving target. .PP \&\fBnocache\fR instructs \s-1CLI\s0 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 \s-1BBU\s0 or \s-1UPS\s0 is installed). By default the cache is enabled. Unless there is a \s-1BBU\s0 or \s-1UPS\s0 installed, to avoid the possibility of data loss in the event of sudden power loss, it is recommended that \fBnocache\fR be specified. .PP \&\fBautoverify\fR enables the autoverify attribute on the unit to be migrated. For more details on this feature, refer to \*(L"cx/ux set autoverify\*(R" section of this document. .PP \&\fB\f(BIMigration Process.\fB\fR 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 \s-1CLI\s0 to \&'remove' and 'rescan' the unit so that the operating system can see the new capacity, and then remount the unit. .PP You may also need to resize the file system or add a new partition. For instructions, consult the documentation for your operating system. .PP \&\fBNote\fR: 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. .PP \&\fB\f(BIExamples.\fB\fR 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. .PP Example of split mirror: .PP .Vb 2 \& //localhost> /c1/u3 migrate type=single \& Sending migration message to /c1/u3 ... Done. .Ve .PP The source unit u3 is a \s-1TWINSTOR\s0 or \s-1RAID\-1\s0, using the \fBmigrate\fR command splits u3 to u3 and u\fIx\fR, each with the \s-1RAID\s0 type of Single. .PP Example of capacity expansion: .PP .Vb 2 \& //localhost> /c0/u3 migrate type=raid10 disk=10-11 stripe=16 \& Sending migration message to /c0/u3 ... Done. .Ve .PP The source unit is u3 and the destination unit is \s-1RAID\-10\s0 with disks 10 and 11 in addition to the disks in the existing unit u3. .PP 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 \&\*(L"/c0/u3 show\*(R" command shows that the source unit is \fIsu3\fR and is of type \s-1RAID\-1\s0, and the destination unit \fIdu3\fR is of type \s-1RAID\-10\s0. .PP .Vb 1 \& 3ware CLI> /c0 show .Ve .PP .Vb 5 \& 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 .Ve .PP .Vb 14 \& 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 .Ve .PP .Vb 1 \& 3ware CLI> /c0/u3 show .Ve .PP .Vb 3 \& Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) \& ------------------------------------------------------------------------ \& u3 Migrator MIGRATING - 39 - - - .Ve .PP .Vb 4 \& 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 .Ve .PP .Vb 8 \& 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 .Ve .PP Please note that the migration path of raidtype Single to \s-1RAID\-1\s0 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 \s-1DEGRADED\s0 until the \*(L"migration\*(R" is complete. .PP For example, below is a system with two migrating units, /c0/u0 and /c0/u1. u0 is migrating from a \s-1RAID\-10\s0 to a \s-1RAID\-0\s0 array, while u1 is migrating from Single to a \s-1RAID\-1\s0, initiated by the following commands: .PP .Vb 1 \& /c0/u0 migrate type=raid0 .Ve .PP and .PP .Vb 1 \& /c0/u1 migrate type=raid1 disk=5 .Ve .PP Note the difference in 'UnitType' and 'Status' of u0 and u1, even though they are both migrating units. .PP .Vb 1 \& 3ware CLI> /c0 show .Ve .PP .Vb 4 \& 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 .Ve .PP .Vb 10 \& 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 - - - - .Ve .PP .Vb 1 \& 3ware CLI> /c0/u3 show .Ve .PP .Vb 3 \& Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) \& ------------------------------------------------------------------------ \& u0 Migrator MIGRATING - 26 - - - .Ve .PP .Vb 8 \& 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 .Ve .PP .Vb 6 \& 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 .Ve .PP .Vb 1 \& 3ware CLI> /c0/u1 show .Ve .PP .Vb 6 \& 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 .Ve .Sh "Port Object Messages" .IX Subsection "Port Object Messages" 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 \fI/c0/p0\fR. \&\fBNote:\fR All references of port also applies to vport for the commands in this section. .RE .IP "\fI/cx/px\fR \fBshow\fR" .IX Item "/cx/px show" This command shows summary information on the specified disk attached to port \&\fI/cx/px\fR. Here is the typical output for controller models up to 9550SX and 9650SE with Release 9.5.1 or earlier: .PP .Vb 1 \& //localhost> /c0/p5 show .Ve .PP .Vb 3 \& Port Status Unit Size Blocks Serial \& --------------------------------------------------------------- \& p5 OK u5 149.05 GB 312581808 WD-WMACK1406498 .Ve .PP This drive summary table indicate that port \fIp5\fR of controller \fIc0\fR is attached to one Western Digital disk with status \s-1OK\s0 and is a part of unit \fIu5\fR. .PP For the 9650SE (with Release 9.5.2 or later), 9690SA, and 9750, the summary information on the specified disk attached to vport \fI/cx/px\fR has a slightly different format. Here is a sample output: .PP .Vb 1 \& //localhost> /c3/p1 show .Ve .PP .Vb 3 \& VPort Status Unit Size Type Phy Encl-Slot Model \& ------------------------------------------------------------------------------ \& p1 OK u0 149.05 GB SATA 0 - WDC WD1600JS-22NCB1a .Ve .PP 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 \*(L"show all\*(R" command.) Please also note that the port handle as a virtual port is indicated by the heading or column \*(L"VPort\*(R". .PP The drive status in the column \*(L"Status\*(R" may display different message strings depending on the detected state of the drive. This is a list of the possible statuses: .PP .Vb 17 \& 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. .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIAttribute Attribute ...\fR" .IX Item "/cx/px show Attribute Attribute ..." This command shows the current setting of the given \fIattribute(s)\fR 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): .PP .Vb 8 \& CONTROLLER | ATTRIBUTES \& -------------------+--------------------------------------------- \& 9550SX and higher | ncq, identify, lspeed, driveinfo \& -------------------+--------------------------------------------- \& 9650SE and higher | rasect, pohrs, temperature, spindlespd \& -------------------+--------------------------------------------- \& 9690SA and 9750 | driveinfo, ports, connections, drvintf, wwn \& -------------------+--------------------------------------------- .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIstatus\fR" .IX Item "/cx/px show status" This command reports the status of the drive associated with the specified port. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show status \& /c0/p5 Status = OK .Ve .PP \&\fBNote:\fR 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 \s-1DEGRADED\s0 and a drive is the degradation point of that unit, the output of this command would not show \s-1DEGRADED\s0 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. .RE .IP "\fI/cx/px\fR \fBshow\fR \fImodel\fR" .IX Item "/cx/px show model" This command reports the model of the drive associated with the specified port. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show model \& /c0/p5 Model = WDC WD1600BB-00DAA0 .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIserial\fR" .IX Item "/cx/px show serial" This command reports the serial number of the drive associated with the specified port. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show serial \& /c0/p5 Serial = WD-WMACK1406498 .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIfirmware\fR" .IX Item "/cx/px show firmware" This command reports the firmware version of the drive associated with the specified port. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show firmware \& /c0/p5 Firmware Version = 65.13G65 .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIidentify\fR (9550SX and higher)" .IX Item "/cx/px show identify (9550SX and higher)" This command reports the identify status of the specified port within an enclosure. The \s-1LED\s0 of the drive slot associated with the specified port would blink if the identify status is \s-1ON\s0. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show identify \& /c0/p5 Identify Status = on .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIncq\fR (9550SX and higher)" .IX Item "/cx/px show ncq (9550SX and higher)" This command reports the \s-1NCQ\s0 (Native Command Queueing) information of the drive associated with the specified port. .PP Example (9550SX): .PP .Vb 3 \& //localhost> /c0/p5 show ncq \& /c0/p5 NCQ Supported = No \& /c0/p5 NCQ Enabled = No .Ve .PP Example (9690SA): .PP .Vb 3 \& //localhost> /c3/p0 show ncq \& /c3/p0 Queuing Supported = Yes \& /c3/p0 Queuing Enabled = Yes .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIlspeed\fR (9550SX and higher)" .IX Item "/cx/px show lspeed (9550SX and higher)" This command reports 1) the \s-1SATA\s0 link speed supported by the drive associated with the specified port and 2) the actual link speed that the specified port is set to. .PP Example: .PP .Vb 3 \& //localhost> /c0/p5 show lspeed \& /c0/p5 SATA Link Speed Supported = 3.0 Gb/s \& /c0/p5 SATA Link Speed = 3.0 Gb/s .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIcapacity\fR" .IX Item "/cx/px show capacity" This command reports the capacity of the drive associated with the specified port in gigabytes (\s-1GB\s0) and in block count. The capacity in \s-1GB\s0 is computed based on division by 1000 and not 1024, as is popular with hard disk vendors. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 show capacity \& /c0/p5 Capacity = 149.05 GB (312581808 Blocks) .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIsmart\fR" .IX Item "/cx/px show smart" This command extracts \s-1SMART\s0 (Self Monitoring Analysis and Reporting) data from the specified \s-1SATA\s0 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 \s-1SMART\s0 data will burden the I/O bandwidth. .PP \&\fBNote:\fR \s-1SMART\s0 data is applicable for \s-1SATA\s0 drives only. Therefore, a request for \s-1SMART\s0 data for a \s-1SAS\s0 drive (as with the 9690SA and 9750 controllers) would result in an error response. .PP \&\fBNote:\fR For \s-1SAS\s0 drives, drive attributes that could be extracted from \s-1SMART\s0 data is available with the following commands: .PP .Vb 4 \& /cx/px show temperature \& /cx/px show spindlespd \& /cx/px show rasect \& /cx/px show pohrs .Ve .PP for temperature, spindle speed, reallocated sectors, and power-on hours, respectively. You may also use '\fI/cx/px show all\fR' for all of the drive attributes. .PP Example (9550SX): .PP .Vb 1 \& //localhost> /c0/p5 show smart .Ve .PP .Vb 32 \& 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 .Ve .PP 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, \s-1CLI\s0 will return an error. .RE .IP "\fI/cx/px\fR \fBshow\fR \fIdriveinfo\fR (9550SX and higher)" .IX Item "/cx/px show driveinfo (9550SX and higher)" This command reports drive and connection information about the drive that is associated with the specified port. .PP Example: .PP .Vb 1 \& //localhost> /c3/p4 show driveinfo .Ve .PP .Vb 4 \& /c3/p4 Drive Type = SAS \& /c3/p4 Interface Type = Direct \& /c3/p4 Drive Ports = 2 \& /c3/p4 Drive Connections = 1 .Ve .RE .IP "\fI/cx/px\fR \fBshow\fR \fIall\fR" .IX Item "/cx/px show all" This command shows the current setting of all above attributes. .RE .IP "\fI/cx/px\fR \fBshow\fR \fIdpmstat\fR \fItype= (9550SX and higher)" .IX Item "/cx/px show dpmstat type= (9550SX and higher)" .RE .PD 0 .IP "\fI/cx/px\fR \fBshow\fR \fIdpmstat\fR \fItype= (9650SE and higher)" .IX Item "/cx/px show dpmstat type= (9650SE and higher)" .PD 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: \fBinst\fR for Instantaneous, \fBra\fR for Running Average, \fBlct\fR for Long Command Times, \&\fBhistdata\fR for Histogram Data, and \fBext\fR 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'. .PP A request for the Running Average statistics, for example: .PP .Vb 1 \& //localhost> /c0/p3 show dpmstat type=ra .Ve .PP .Vb 4 \& Queue Xfer Resp \& Port Status Unit Depth IOPs Rate(MB/s) Time(ms) \& --------------------------------------------------------------------- \& p3 OK u0 0 435 25.249 2 .Ve .PP Or for the Long Command Times statistics, for example: .PP .Vb 1 \& //localhost> /c0/p3 show dpmstat type=lct .Ve .PP .Vb 3 \& Port Status Unit \& ------------------------------ \& p3 OK u0 .Ve .PP .Vb 13 \& 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 .Ve .PP For examples of other statistic data types, please see \*(L"Drive Performance Monitor\*(R" in the 'Features' section. .RE .IP "\fI/cx/px\fR \fBremove\fR [\fInoscan\fR] [\fIquiet\fR]" .IX Item "/cx/px remove [noscan] [quiet]" This command allows you to remove (or export) a port \fB/cx/px\fR (or drive). Exporting a port will instruct the firmware to remove the specified port from its pool of managed ports, but retains the \s-1DCB\s0 (Disk Configuration Block) meta-data on the attached disk. You can import (or re\-introduce) the port via the \fBrescan\fR command. Use \fInoscan\fR to bypass informing the \s-1OS\s0 of this change. Default is to inform the \s-1OS\s0. The quiet option is for the non-interactive mode. .PP 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. .RE .IP "\fI/cx/px\fR \fBset\fR \fIidentify= (9550SX and higher)" .IX Item "/cx/px set identify= (9550SX and higher)" This command sets the identify status of the specified port within an enclosure. If set to \s-1ON\s0, the \s-1LED\s0 of the drive slot associated with the specified port would blink. .PP Example: .PP .Vb 2 \& //localhost> /c0/p5 set identify=on \& Setting Port Identify on /c0/p5 to [on] ... Done. .Ve .RE .IP "\fI/cx/px\fR \fBset\fR \fIdpmstat= \fI[type=ra|lct]\fR (9550SX and higher)" .IX Item "/cx/px set dpmstat= [type=ra|lct] (9550SX and higher)" .RE .PD 0 .IP "\fI/cx/px\fR \fBset\fR \fIdpmstat= \fI[type=ra|lct|ext]\fR (9650SE and higher)" .IX Item "/cx/px set dpmstat= [type=ra|lct|ext] (9650SE and higher)" .PD 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: \fBra\fR for Running Average, \fBlct\fR for Long Command Times,and \fBext\fR for Extended Drive Statistics. More detailed information regarding these statistics and the Drive Performance Monitor is available in the \&\fBFeatures\fR section under 'Drive Performance Monitor'. .PP 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. .PP Here is an example of clearing the Running Average and Histdata statistics: .PP .Vb 3 \& //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. .Ve .PP 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: .PP .Vb 1 \& //localhost> /c0/p3 show dpmstat type=ra .Ve .PP .Vb 4 \& Queue Xfer Resp \& Port Status Unit Depth IOPs Rate(MB/s) Time(ms) \& --------------------------------------------------------------------- \& p3 OK u0 0 0 0.000 0 .Ve .PP Similarly, the display for Histogram data would show all zeros. .PP For examples of other statistic data types, please see 'Drive Performance Monitor' in the 'Features' section. .Sh "Phy Object Messages" .IX Subsection "Phy Object Messages" Phy Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller phy such as \fI/c0/phy0\fR. .RE .IP "\fI/cx/phyx\fR \fBshow\fR" .IX Item "/cx/phyx show" 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 \s-1SATA\s0 or \s-1SAS\s0. The 'Device' column is the device \s-1ID\s0 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. .PP Example: .PP .Vb 1 \& //localhost> /c3/phy0 show .Ve .PP .Vb 4 \& 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 .Ve .RE .IP "\fI/cx/phyx\fR \fBset\fR \fIlink= (9650SE and higher)" .IX Item "/cx/phyx set link= (9650SE and higher)" 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 \fIauto\fR. .PP Example: .PP .Vb 3 \& //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. .Ve .PP \&\fBNote:\fR 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. .PP See alo: .PP .Vb 2 \& /cx show phy \& /cx/phyx show .Ve .RE .IP "\fI/cx/phyx\fR \fBset\fR \fIlink= (9750 only)" .IX Item "/cx/phyx set link= (9750 only)" 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 \fIauto\fR. .PP Example: .PP .Vb 3 \& //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. .Ve .PP \&\fBNote:\fR 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. .PP See alo: .PP .Vb 2 \& /cx show phy \& /cx/phyx show .Ve .Sh "\s-1BBU\s0 Object Messages" .IX Subsection "BBU Object Messages" \&\s-1BBU\s0 (Battery Backup Unit) Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a \s-1BBU\s0 such as \fI/c0/bbu\fR. The commands in this section are available on 9000 series controllers where the \s-1BBU\s0 is installed. .RE .IP "\fI/cx/bbu\fR \fBshow\fR" .IX Item "/cx/bbu show" This command reports summary information on the specified \s-1BBU\s0 object. .PP Example: .PP .Vb 1 \& //localhost> /cx/bbu show .Ve .PP .Vb 3 \& Name OnlineState BBUReady Status Volt Temp Hours LastCapTest \& --------------------------------------------------------------------------- \& bbu On No Testing OK OK 72 01-Jul-2009 .Ve .PP 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 \s-1BBU\s0 unit is currently testing the battery. Both voltage and temperature are normal. The \s-1BBU\s0 is \fBnot\fR ready for backup of the write cache on the controller due to the testing. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIAttribute Attribute ...\fR" .IX Item "/cx/bbu show Attribute Attribute ..." This command shows the current setting of the given \fIattribute(s)\fR on the \&\s-1BBU\s0 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. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIstatus\fR" .IX Item "/cx/bbu show status" This command \fBshow\fRs the status of the \s-1BBU\s0. Possible values are: .Sp .RS 4 \&\fBTesting\fR .Sp Battery test is currently in progress. It may take up to 24 hours to complete. During the test, the \s-1BBU\s0 is \fBnot\fR capable of backup operation and the write cache of the applicable \s-1RAID\s0 units are also disabled. If the test is completed with no error and the \s-1BBU\s0 returns back to WeakBat or \s-1OK\s0 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. .Sp \&\fBCharging\fR .Sp \&\s-1BBU\s0 is currently charging the battery. The charging is started automatically by the \s-1BBU\s0 whenever necessary. During the charging, the \s-1BBU\s0 is \fBnot\fR capable of backup operation and the write cache is disabled. Once charging is completed and the \s-1BBU\s0 returns back to \s-1OK\s0 status, the write cache will be resumed. If a \s-1FAULT\s0 or an \s-1ERROR\s0 occurs during the test, the write cache remains at the disabled state until the problem is fixed. .Sp \&\fBFault\fR .Sp A battery fault is detected. At this state, the \s-1BBU\s0 is \fBnot\fR capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the \s-1BBU\s0 board to fix the problem as soon as possible so that the write cache will be enabled again. .Sp \&\fBError\fR .Sp Other \s-1BBU\s0 error is detected. At this state, the \s-1BBU\s0 is \fBnot\fR capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the \s-1BBU\s0 board to fix the problem as soon as possible so that the write cache will be enabled again. .Sp \&\fBFailed\fR .Sp The battery failed a test. At this state, the \s-1BBU\s0 is \fBnot\fR capable of backup operation and the write cache is disabled. We recommend you to replace the battery and/or the \s-1BBU\s0 board to fix the problem as soon as possible so that the write cache will be enabled again. .Sp \&\fBWeakBat\fR .Sp \&\s-1BBU\s0 is functioning normally which means it is online and capable of backing up the write cache. But the battery is \fBweak\fR and should be \fBreplaced\fR. .Sp \&\fB\s-1OK\s0\fR .Sp \&\s-1BBU\s0 is ready, online and capable of backing up the write cache. .Sp \&\fB\-\fR .Sp Battery is not present or \s-1BBU\s0 unit is not installed. .RE .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIbatinst\fR" .IX Item "/cx/bbu show batinst" This command reports the date when the current battery was installed. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIlasttest\fR" .IX Item "/cx/bbu show lasttest" This command reports the date the battery capacity was last measured. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIvolt\fR" .IX Item "/cx/bbu show volt" This command reports the voltage status of the battery. The status can be \s-1OK\s0, \&\s-1HIGH\s0, \s-1LOW\s0, \s-1TOO\-HIGH\s0, and \s-1TOO\-LOW\s0. The \s-1HIGH\s0 and \s-1LOW\s0 are in warning range. TOO-HIGH and TOO-LOW are out of the operating range and need to be concerned. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fItemp\fR" .IX Item "/cx/bbu show temp" .RE .PD 0 .IP "\fI/cx/bbu\fR \fBshow\fR \fItempstat\fR" .IX Item "/cx/bbu show tempstat" .PD This command reports the temperature status of the battery. The status can be \&\s-1OK\s0, \s-1HIGH\s0, \s-1LOW\s0, \s-1TOO\-HIGH\s0, and \s-1TOO\-LOW\s0. The \s-1HIGH\s0 and \s-1LOW\s0 are in warning range. TOO-HIGH and TOO-LOW are out of the operating range and need to be concerned. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fItempval\fR" .IX Item "/cx/bbu show tempval" This command reports the detected temperature value in the battery. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIcap\fR" .IX Item "/cx/bbu show cap" This command reports the battery capacity in hours. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIserial\fR" .IX Item "/cx/bbu show serial" This command reports the \s-1BBU\s0 serial number. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIfw\fR" .IX Item "/cx/bbu show fw" This command reports the \s-1BBU\s0 board firmware version number. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIpcb\fR" .IX Item "/cx/bbu show pcb" This command reports the \s-1PCB\s0 revision number on the \s-1BBU\s0 unit. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIbootloader\fR" .IX Item "/cx/bbu show bootloader" This command reports the \s-1BBU\s0's Boot Loader version. .RE .IP "\fI/cx/bbu\fR \fBshow\fR \fIall\fR" .IX Item "/cx/bbu show all" This command shows the current settings of all above attributes on the \s-1BBU\s0 board. .PP Example: .PP .Vb 1 \& //localhost> /c1/bbu show all .Ve .PP .Vb 12 \& /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 .Ve .RE .IP "\fI/cx/bbu\fR \fBtest\fR [\fIquiet\fR]" .IX Item "/cx/bbu test [quiet]" This command starts the battery capacity test. The test may take up to 24 hours to complete. During the test, the \s-1BBU\s0 is \fBnot\fR 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 \s-1BBU\s0 returns back to \s-1OK\s0 state, the write cache will be resumed. The quiet option is for non-interactive mode. .PP After the test has initiated, check the controller alarms for any AENs (Asynchronous Event Notifications) about the status of the test operation. .PP \&\fBNote:\fR The test cannot be terminated before it completes. .RE .IP "\fI/cx/bbu\fR \fBenable\fR" .IX Item "/cx/bbu enable" This command enables \s-1BBU\s0 detection on the controller. The controller will utilize \s-1BBU\s0 functionality in the event of power failure if \s-1BBU\s0 is there and ready. .RE .IP "\fI/cx/bbu\fR \fBdisable\fR \fB[quiet]\fR" .IX Item "/cx/bbu disable [quiet]" This command disables \s-1BBU\s0 detection on the controller. The controller ignores the existence of the \s-1BBU\s0 when \s-1BBU\s0 detection is disabled. In another words, despite a \s-1BBU\s0 being attached to a controller, with \s-1BBU\s0 detection disabled, storage management software will report that there is no \s-1BBU\s0 installed on this controller. The quiet option is for non-interactive mode. .Sh "Enclosure Object Messages" .IX Subsection "Enclosure Object Messages" 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. .PP 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 \s-1CCU\s0 enclosure, simply drop the pre-pended controller name in the command, as, not '/c1/e0' but '/e0'. .PP The following table summarizes the supported controllers, protocols, configurations, and enclosure elements. .PP .Vb 17 \& --------------------------+------------------------------------------ \& 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 \& -----------+--------------+------------+-----------+----------------- .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR" .IX Item "/cx/ex show" This command shows summary information on the specified enclosure \fI/ex\fR, 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 \fBEnclosure\fR section, a \fBFan\fR section, a \fBTemperature Sensor\fR section, and a \fBSlot\fR section. .PP Typical output looks like: .PP .Vb 1 \& //localhost> /c0/e0 show .Ve .PP .Vb 3 \& Encl Status \& --------------------------- \& /c0/e0 OK .Ve .PP .Vb 8 \& 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 .Ve .PP .Vb 10 \& 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 .Ve .PP .Vb 4 \& PowerSupply Status State Voltage Current Identify \& --------------------------------------------------------------------------- \& pwrs0 OK on OK OK Off \& pwrs1 OK on OK OK Off .Ve .PP .Vb 14 \& 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 .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIAttribute\fR \fIAttribute ...\fR" .IX Item "/cx/ex show Attribute Attribute ..." This command shows the current setting of the given \fIattribute(s)\fR. 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. .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIvendor\fR" .IX Item "/cx/ex show vendor" This command reports the product vendor of the specified enclosure. .PP Example: .PP .Vb 2 \& //localhost> /c1/e0 show vendor \& /c1/e0 Vendor = LSI .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIprodid\fR" .IX Item "/cx/ex show prodid" This command reports the product \s-1ID\s0 of the specified enclosure. .PP Example: .PP .Vb 2 \& //localhost> /c1/e0 show prodid \& /c1/e0 Product ID = DE1600-SAS .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIprodrev\fR" .IX Item "/cx/ex show prodrev" This command reports the product revision of the specified enclosure. .PP Example: .PP .Vb 2 \& //localhost> /c1/e0 show prodrev \& /c1/e0 Product Revision = 0314 .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIfirmware\fR (9690SA and 9750 only)" .IX Item "/cx/ex show firmware (9690SA and 9750 only)" This command reports the \s-1SEP\s0(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. .PP Example: .PP .Vb 3 \& //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 .Ve .PP See also: .PP .Vb 1 \& /cx/ex update fw=filename_with_path [sep=n] [force] .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIcontrollers\fR" .IX Item "/cx/ex show controllers" 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. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0 show controllers \& /c0/e0 connects to controller /c0 .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIslots\fR" .IX Item "/cx/ex show slots" 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. .PP Example: .PP .Vb 1 \& //localhost> /e0 show slots .Ve .PP .Vb 6 \& Slot Status (V)Port Identify \& ---------------------------------------------------- \& slot0 OK /c0/p0 No \& slot1 OK /c0/p1 Yes \& slot2 NO-DEVICE - No \& slot3 NO-DEVICE - No .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIfans\fR" .IX Item "/cx/ex show fans" 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 \s-1ON\s0 or \s-1OFF\s0. The two columns related to fan speed shows the level and \s-1RPM\s0 (revolutions per minute), and finally, the Identify column lists the Identify setting of the fans. .PP Example: .PP .Vb 10 \& //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 .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fItemps\fR" .IX Item "/cx/ex show temps" 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. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0 show temps .Ve .PP .Vb 10 \& 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 .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIpwrs\fR" .IX Item "/cx/ex show pwrs" 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 \s-1ON\s0 or \s-1OFF\s0, 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. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0 show pwrs .Ve .PP .Vb 4 \& PowerSupply Status State Voltage Current Identify \& --------------------------------------------------------------------------- \& pwrs0 OK on OK OK Off \& pwrs1 OK on OK OK Off .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIalarms\fR" .IX Item "/cx/ex show alarms" .RE .PD 0 .IP "\fI/cx/ex\fR \fBshow\fR \fIalms\fR" .IX Item "/cx/ex show alms" .PD 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 \s-1ON\s0 or \s-1OFF\s0, and the Audibility column indicate whether the alarm is unmute or muted. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0 show alarms .Ve .PP .Vb 3 \& Alarm Status State Audibility \& --------------------------------------------------- \& alm0 OK OFF UNMUTE .Ve .RE .IP "\fI/cx/ex\fR \fBshow\fR \fIall\fR" .IX Item "/cx/ex show all" This command shows the current setting of all the enclosure attributes and the enclosure summary tables. .RE .IP "\fI/cx/ex\fR \fBupdate\fR \fIfw=filename_with_path\fR \fB[sep=n] [force]\fR (9690SA and 9750 only)" .IX Item "/cx/ex update fw=filename_with_path [sep=n] [force] (9690SA and 9750 only)" This command allows you to download a specified expander firmware image to the target \s-1SEP\s0 (Storage Enclosure Processor) expander that supports the \s-1SES\-2\s0 (\s-1SCSI\s0 Enclosure Services) standard for enclosure management. (\s-1CCU\s0 enclosures with SAF-TE protocol are not supported.) .PP This command is for the 9690SA and 9750 controllers with Release 10.2 or later only. .PP The \fBfw=filename_with_path\fR attribute allows you to specify the firmware image file name along with its path. Please note that \fIfilename_with_path\fR could not have spaces (as Windows allows). .PP The firmware image specified by \fIfilename_with_path\fR 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 \s-1SEP\s0 number and the firmware versions. You are then asked with a prompt to continue. If you enter \*(L"y\*(R", the download process will initiate. .PP The \fBsep=n\fR attribute is optional. It identifies the target \s-1SEP\s0 expander in the system. Valid range is {0..9}. Without it being specified, the default which is 0 (zero), will be used. .PP The \fBforce\fR attribute is optional. With it the warning message, version check, and prompt to proceed are all bypassed. The image will initiate the download immediately. .PP \&\fB\s-1IMPORTANT\s0! Please note the following regarding usage of this command.\fR .PP 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: . Click on the \fIData and Interoperability\fR tab, and then click on the \fI3ware Interoperability Information\fR link to check if your expander is supported. .PP 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. .PP 3) The expander requires reboot for the new firmware image to take effect. .PP Example: .PP .Vb 1 \& //localhost> /c1/e0 update fw=c:\etmp\eBadger_0314.esm .Ve .PP .Vb 3 \& Warning: Updating firmware that is incompatible with your device can \& render the device unusable. Before you update the firmware, it is \& recommended that you: .Ve .PP .Vb 1 \& 1) Backup your data. .Ve .PP .Vb 1 \& 2) Verify with your enclosure vendor that you have the correct image. .Ve .PP .Vb 2 \& 3) Have a copy of the existing expander firmware image so that \& you can roll back, if necessary. .Ve .PP .Vb 2 \& 4) Make sure there is no I/O activity between the controller and \& the target expander (see instructions in user documentation). .Ve .PP .Vb 1 \& Examining firmware image for download to /c1/e0 ... Done. .Ve .PP .Vb 1 \& Download version is newer than current. .Ve .PP .Vb 3 \& SEP New-Firmware Current-Firmware Vendor \& ---------------------------------------------------------------- \& 0 90.00.03.15 80.00.03.13 LSI .Ve .PP .Vb 2 \& Given the above compatibility information ... \& Do you want to continue? Y|N [N]: y .Ve .PP .Vb 2 \& Downloading the expander firmware from file [c:\etmp\eBadger_0315.esm] ... Done. \& The new image will take effect after reboot. .Ve .PP In the output response to the command above, after .PP .Vb 1 \& Examining firmware image for download to /c1/e0 ... Done. .Ve .PP A message is displayed regarding the version examination. In the example, it shows \*(L"Download version is newer than current.\*(R" Depending on the examination, the message may be one of: .PP .Vb 4 \& Download version is newer than current. \& Download version is older than current. \& Both versions are the same. \& Version not known. .Ve .PP If an error is detected in the examination, the message you will see may be one of: .PP .Vb 5 \& 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. .Ve .PP See also: .PP .Vb 1 \& /cx/ex show firmware .Ve .PP \fIEnclosure Element Slot\fR .IX Subsection "Enclosure Element Slot" .PP The slot commands provide information about the slot elements in the enclosure unit. .RE .IP "\fI/cx/ex/slotx\fR \fBshow\fR" .IX Item "/cx/ex/slotx show" This command shows slot information on the specified enclosure \fI/ex\fR. 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 \s-1OK\s0. If the slot is empty the status would indicate \s-1NO\-DEVICE\s0. 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. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0/slot1 show .Ve .PP .Vb 3 \& Slot Status (V)Port Identify \& ---------------------------------------------------- \& slot1 OK /c0/p1 On .Ve .RE .IP "\fI/cx/ex/slotx\fR \fBshow\fR \fIidentify\fR" .IX Item "/cx/ex/slotx show identify" This command shows the identify status of the specified enclosure slot. If Identify = \s-1ON\s0, the \s-1LED\s0 associated with the slot will blink. Likewise, for Identify = \s-1OFF\s0, the \s-1LED\s0 associated will stop blinking or would not blink. If the enclosure does not support Slot Identify, this command will respond with \&'N/A'. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/slot1 show identify \& /c0/e0/slot1 Identify status = on .Ve .RE .IP "\fI/cx/ex/slotx\fR \fBset\fR \fIidentify=" .IX Item "/cx/ex/slotx set identify=" This command identifies the specified slot by setting the identify attribute to either \s-1ON\s0 or \s-1OFF\s0, if there is an \s-1LED\s0 associated and if the enclosure supports Slot Identify. If supported, setting it to \s-1ON\s0 will blink the \s-1LED\s0 of the specified drive slot. For example: .PP .Vb 2 \& //localhost> /c0/e0/slot1 set identify=on \& Setting Slot Identify on /c0/e0/slot1 to [on] ... Done. .Ve .PP \fIEnclosure Element Fan\fR .IX Subsection "Enclosure Element Fan" .PP These commands provide information about the fans in the enclosure unit. .RE .IP "\fI/cx/ex/fanx\fR \fBshow\fR" .IX Item "/cx/ex/fanx show" This command shows information about the specified enclosure fan. .PP Example: .PP .Vb 5 \& //localhost> /c0/e0/fan0 show \& ---Speed--- \& Fan Status State Step RPM Identify \& ------------------------------------------------------------ \& fan0 OK ON 1 2700 Off .Ve .RE .IP "\fI/cx/ex/fanx\fR \fBshow\fR \fIidentify\fR" .IX Item "/cx/ex/fanx show identify" This command shows the identify status of the specified enclosure fan. If Identify = \s-1ON\s0, the \s-1LED\s0 associated with the fan will blink. Likewise, for Identify = \s-1OFF\s0, the \s-1LED\s0 associated will stop blinking or would not blink. If the enclosure does not support Fan Identify, this command will respond with \&'N/A'. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/fan0 show identify \& /c0/e0/fan0 Identify status = off .Ve .RE .IP "\fI/cx/ex/fanx\fR \fBset\fR \fIidentify=" .IX Item "/cx/ex/fanx set identify=" This command identifies the specified enclosure fan by setting the identify attribute to either on or off, if there is an \s-1LED\s0 associated and if the enclosure supports Fan Identify. If supported, setting it to \s-1ON\s0 will blink the \s-1LED\s0 associated with the specified fan element. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/fan1 set identify=on \& Setting Fan Identify on /c0/e0/fan1 to [on] ... Done. .Ve .RE .IP "\fI/cx/ex/fanx\fR \fBset\fR \fIspeed=<0..7\fR>" .IX Item "/cx/ex/fanx set speed=<0..7>" This command sets the speed level of the specified enclosure fan. The speed level is a number in the range of <0..7>, where: .PP .Vb 8 \& 0 - Off \& 1 - Lowest \& 2 - Low \& 3 - Medium-low \& 4 - Medium \& 5 - Medium-high \& 6 - High \& 7 - Highest .Ve .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/fan1 set speed=1 \& Setting Fan Speed on /c0/e0/fan1 to [1] ... Done. .Ve .PP \fIEnclosure Element Temperature Sensor\fR .IX Subsection "Enclosure Element Temperature Sensor" .PP These commands provide information about the temperature sensors in the enclosure unit. .RE .IP "\fI/cx/ex/tempx\fR \fBshow\fR" .IX Item "/cx/ex/tempx show" This command shows information about the specified enclosure temperature sensor. The possible status values are \s-1OK\s0, \s-1OVER\-WARNING\s0, \s-1OVER\-FAIL\s0, \s-1UNDER\-WARNING\s0, \&\s-1UNDER\-FAIL\s0, where \s-1OVER\s0 denotes over-temperature and \s-1UNDER\s0 denotes under\-temperature. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0/temp0 show .Ve .PP .Vb 3 \& TempSensor Status Temperature Identify \& -------------------------------------------------------- \& temp0 OK 42C(107F) Off .Ve .RE .IP "\fI/cx/ex/tempx\fR \fBshow\fR \fIidentify\fR" .IX Item "/cx/ex/tempx show identify" This command shows the identify status of the specified enclosure temperature sensor. If Identify = \s-1ON\s0, the \s-1LED\s0 associated with the temperature sensor will blink. Likewise, for Identify = \s-1OFF\s0, the \s-1LED\s0 associated will stop blinking or would not blink. If the enclosure does not support Temperature Sensor Identify, this command will respond with 'N/A'. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/temp0 show identify \& /c0/e0/temp0 Identify status = off .Ve .RE .IP "\fI/cx/ex/tempx\fR \fBset\fR \fIidentify=" .IX Item "/cx/ex/tempx set identify=" This command identifies the specified enclosure temperature sensor by setting the identify attribute to either \s-1ON\s0 or \s-1OFF\s0, if there is an \s-1LED\s0 associated and if the enclosure supports Temperature Sensor Identify. If supported, setting it to \&\s-1ON\s0 will blink the \s-1LED\s0 associated with the specified temperature element. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/temp1 set identify=on \& Setting Temperature Sensor Identify on /c0/e0/temp1 to [on] ... Done. .Ve .PP \fIEnclosure Element Power Supply\fR .IX Subsection "Enclosure Element Power Supply" .PP These commands provide information about the enclosure power supplies in the enclosure unit. .RE .IP "\fI/cx/ex/pwrsx\fR \fBshow\fR" .IX Item "/cx/ex/pwrsx show" This command shows information about the specified enclosure power supply. The possible status values are \s-1OK\s0, \s-1FAIL\s0, \s-1NOT\-INSTALLED\s0, and \s-1OFF\s0. The voltage and current columns indicate the threshold voltage and current status. The possible values for Voltage are \s-1OK\s0, \s-1OVER\-VOLTAGE\s0, and \s-1UNDER\-VOLTAGE\s0. The possible values for Current are \s-1OK\s0 and \s-1OVER\-CURRENT\s0. In either case, \&\s-1OVER\-\s0 means over the set threshold of the voltage or current. .PP Example: .PP .Vb 1 \& //localhost> /c0/e0/pwrs0 show .Ve .PP .Vb 3 \& PowerSupply Status State Voltage Current Identify \& --------------------------------------------------------------------------- \& pwrs0 OK on OK OK Off .Ve .RE .IP "\fI/cx/ex/pwrsx\fR \fBshow\fR \fIidentify\fR" .IX Item "/cx/ex/pwrsx show identify" This command shows the identify status of the specified enclosure power supply. If Identify = \s-1ON\s0, the \s-1LED\s0 associated with the fan will blink. Likewise, for Identify = \s-1OFF\s0, the \s-1LED\s0 associated will stop blinking or would not blink. If the enclosure does not support Power Supply Identify, this command will respond with 'N/A'. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/pwrs0 show identify \& /c0/e0/pwrs0 Identify status = off .Ve .RE .IP "\fI/cx/ex/pwrsx\fR \fBset\fR \fIidentify=" .IX Item "/cx/ex/pwrsx set identify=" This command identifies the specified enclosure power supply by setting the identify attribute to either \s-1ON\s0 or \s-1OFF\s0, if there is an \s-1LED\s0 associated and if the enclosure supports Power Supply Identify. If supported, setting it to \s-1ON\s0 will blink the \s-1LED\s0 associated with the specified power supply. .PP Example: .PP .Vb 2 \& //localhost> /c0/e0/pwrs1 set identify=on \& Setting Power Supply Identify on /c0/e0/pwrs1 to [on] ... Done. .Ve .PP \fIEnclosure Element Alarm\fR .IX Subsection "Enclosure Element Alarm" .PP These commands provide information about the enclosure alarms in the enclosure unit. .RE .IP "\fI/cx/ex/pwrsx\fR \fBshow\fR" .IX Item "/cx/ex/pwrsx show" This command shows information about the specified enclosure alarm. The possible status values are \s-1OK\s0, \s-1FAIL\s0, \s-1NOT\-INSTALLED\s0, and \s-1ACTIVATED\s0. The status values are described below. The possible values for State are \s-1ON\s0 and \s-1OFF\s0. The possible values for Audibility are \s-1UNMUTE\s0 and \s-1MUTE\s0. .PP Possible Status values: .PP .Vb 5 \& 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. .Ve .PP Example: .PP .Vb 1 \& //localhost> /c0/e0/alm0 show .Ve .PP .Vb 3 \& Alarm Status State Audibility \& --------------------------------------------------- \& alm0 OK OFF UNMUTE .Ve .RE .IP "\fI/cx/ex/almx\fR \fBset\fR \fIalarm=" .IX Item "/cx/ex/almx set alarm=" 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. .PP \&\fBNote:\fR Some enclosures support alarms but not the mute/unmute function. For these enclosures, the command to set the alarm to \fImute\fR will return an error message indicating that the feature is not supported. In this case, the alarm setting of \fIunmute\fR would seem to be supported. This is because the \fIunmute\fR 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: .PP .Vb 2 \& //localhost> /c0/e0/alm0 set alarm=unmute \& Setting alarm audibility setting of /c0/e0/alm0 to [unmute] ... Done. .Ve .PP \&\fBNote:\fR You \fIcannot\fR turn \s-1ON\s0 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 \s-1ON\s0 will return an error. .PP 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 \s-1OFF\s0. You could also mute the alarm. The difference between using either is the following: .PP .Vb 4 \& State or Audibility Persistence across reboot \& ------------------- ------------------------- \& ON/OFF Yes \& MUTE/UNMUTE No .Ve .PP For \s-1OFF\s0, 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). .PP For \s-1MUTE\s0, 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). .PP For enclosures that do not support \s-1MUTE\s0, there is no difference between \s-1OFF\s0 and \s-1MUTE\s0. .PP The default values are \s-1UNMUTE\s0 and \s-1OFF\s0. .SH "Help Commands" .IX Header "Help Commands" 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. .PP At top level of online help shows the set of objects that Help provides, these includes the shell object, and controller and enclosure objects: .PP .Vb 1 \& //localhost> help .Ve .PP .Vb 2 \& Copyright (c) 2010 LSI \& LSI/3ware CLI (version 2.00.11.014) .Ve .PP .Vb 14 \& 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) .Ve .PP .Vb 3 \& Certain commands are qualified with constraints of controller type/model \& support. Please consult the tw_cli documentation for explanation of the \& controller-qualifiers. .Ve .PP .Vb 2 \& Type help to get more details about a particular command. \& For more detail information see tw_cli's documentation. .Ve .PP Please note that the version of \s-1CLI\s0 is indicated at the top of the output. .PP As indicated, \fBhelp 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: .PP .Vb 1 \& //localhost> help /cx .Ve .PP .Vb 23 \& /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=] \& (9550SX and higher for type=inst and type=ra; \& 9650SE and higher for type=ext) .Ve .PP .Vb 13 \& /cx add type= disk= (where p = port or drive number) \& [stripe=] [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=] (9550SX and higher) \& [noscan] [rapidrecovery=] (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) .Ve .PP .Vb 3 \& /cx del rebuild=slot_id (9000 series) \& /cx del verify=slot_id (9000 series) \& /cx del selftest=slot_id (9000 series) .Ve .PP .Vb 18 \& /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= (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= (see note 3) \& /cx set selftest=enable|disable (9000 series) \& /cx set autorebuild=on|off (9550SX and higher) \& /cx set autodetect=on|off disk=|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) .Ve .PP .Vb 6 \& /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. .Ve .PP .Vb 11 \& 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. .Ve .PP For Help on the next level, i.e., for the commands \fBshow\fR, \fBadd\fR, \fBdel\fR, \&\fBset\fR, \fBupdate\fR, \fBflush\fR, \fBcommit\fR, etc, use for example, \fBhelp /cx add\fR to see the syntax of the add commands associated with /cx: .PP .Vb 14 \& //localhost> help /cx add \& /cx add type= disk= (where p = port or drive number) \& [stripe=] [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=] (9550SX and higher) \& [noscan] [rapidrecovery=] (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) .Ve .PP .Vb 11 \& 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. .Ve .PP \&\fBNote:\fR 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. .PP 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: .PP .Vb 24 \& //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=] \& (9550SX and higher for type=inst and type=ra; \& 9650SE and higher for type=ext) .Ve .PP .Vb 11 \& 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. .Ve .PP \&\fBNote:\fR 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 \fB/c0 show phy\fR followed by \fB/c0 show ?\fR. 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: .PP .Vb 2 \& //localhost> /c4 show ? \& Error: (CLI:003) Specified controller does not exist. .Ve .PP The following lists the Help Commands, with a brief description for each command. .RE .IP "\fBhelp\fR" .IX Item "help" This command provide a table of contents, providing an overall navigational help. Typical output looks like: .PP .Vb 1 \& //localhost> help .Ve .PP .Vb 2 \& Copyright (c) 2010 LSI \& LSI/3ware CLI (version 2.00.11.014) .Ve .PP .Vb 14 \& 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) .Ve .PP .Vb 3 \& Certain commands are qualified with constraints of controller type/model \& support. Please consult the tw_cli documentation for explanation of the \& controller-qualifiers. .Ve .PP .Vb 2 \& Type help to get more details about a particular command. \& For more detail information see tw_cli's documentation. .Ve .RE .IP "\fBhelp\fR \fIshow\fR" .IX Item "help show" This command provides specific \fIshow\fR related help, illustrating various ways to use the \fIshow\fR command. It provides reports on Controllers, Units and Drives. See the \*(L"Shell Object Messages\*(R" section for more on show. .RE .IP "\fBhelp\fR \fIflush\fR" .IX Item "help flush" This command provides specific \fIflush\fR related help, illustrating various ways to use the \fIflush\fR command. See the \*(L"Shell Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fIrescan\fR" .IX Item "help rescan" This command provides specific \fIrescan\fR related help, illustrating various ways to use the \fIrescan\fR command. See the \*(L"Shell Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fIupdate\fR" .IX Item "help update" This command provides specific \fIupdate\fR related help. See the \&\*(L"Shell Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fIcommit\fR" .IX Item "help commit" This command provides specific \fIcommit\fR related help, illustrating various ways to use the \fIcommit\fR command. See the \*(L"Shell Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fIfocus\fR" .IX Item "help focus" This command provides specific \fIfocus\fR related help, illustrating various ways to use the \fIfocus\fR command. See the \*(L"Shell Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx\fR" .IX Item "help /cx" This command provides specific controller \fI/cx\fR related help, illustrating various commands associated with the controller \fI/cx\fR. See the \*(L"Controller Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ux\fR" .IX Item "help /cx/ux" This command provides specific unit \fI/cx/ux\fR related help, illustrating various commands to use on a unit \fI/cx/ux\fR. See the \*(L"Controller Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/px\fR" .IX Item "help /cx/px" This command provides specific \fI/cx/px\fR related help, illustrating various ways to use the \fI/cx/px\fR command. See the \*(L"Port Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/phyx\fR" .IX Item "help /cx/phyx" This command provides specific \fI/cx/phyx\fR related help, illustrating various ways to use the \fI/cx/phyx\fR command. See the \*(L"Phy Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/bbu\fR" .IX Item "help /cx/bbu" This command provides specific \fI/cx/bbu\fR related help, illustrating various ways to use the \fI/cx/bbu\fR command. See the \*(L"\s-1BBU\s0 Object Messages\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ex\fR" .IX Item "help /cx/ex" This command provides specific enclosure \fI/cx/ex\fR related help, illustrating various commands associated with the enclosure \fI/cx/ex\fR. See the \*(L"Enclosure Services Commands\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ex/slotx\fR" .IX Item "help /cx/ex/slotx" This command provides specific slot \fI/cx/ex/slotx\fR related help, illustrating various ways to use the \fI/cx/ex/slotx\fR command. See the \*(L"Enclosure Element Slot\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ex/fanx\fR" .IX Item "help /cx/ex/fanx" This command provides specific fan \fI/cx/ex/fanx\fR related help, illustrating various ways to use the \fI/cx/ex/fanx\fR command. See the \*(L"Enclosure Element Fan\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ex/tempx\fR" .IX Item "help /cx/ex/tempx" This command provides specific temperature sensor \fI/cx/ex/tempx\fR related help, illustrating various ways to use the \fI/cx/ex/tempx\fR command. See the \&\*(L"Enclosure Element Temperature Sensor\*(R" section for more. .RE .IP "\fBhelp\fR \fI/cx/ex/pwrsx\fR" .IX Item "help /cx/ex/pwrsx" This command provides specific power supply /cx/ex/pwrsx related help, illustrating various ways to use the /cx/ex/pwrsx command. See the \&\*(L"Enclosure Element Power Supply\*(R" section for more. .SH "Command Logging" .IX Header "Command Logging" \&\s-1CLI\s0 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 \s-1CLI\s0 and 3DM2 has this logging function and it is enabled by default. .PP Setting the environment variable to \s-1ON\s0 or \s-1OFF\s0 will enable or disable the logging function, respectively. The environment variable is \s-1TW_CLI_LOG\s0, and the method for setting it depends on the operating system. .PP The sections and examples below show the log command syntax and the log file location depending on the operating system. Note where \s-1ON\s0 is indicated, \s-1OFF\s0 may be substituted. .RE .IP "Setting of Environment Variable:" .IX Item "Setting of Environment Variable:" For \fBLinux\fR, \fBFreeBSD\fR, \fBMac \s-1OS\s0\fR, and \fBOpenSolaris\fR, the command depends on the type of shell: .PP .Vb 2 \& If bash, ksh, or sh, use "export TW_CLI_LOG=ON" \& If csh, use "setenv TW_CLI_LOG ON" .Ve .PP \&\fBNote:\fR The shell that you are running \s-1CLI\s0 must be the same shell that you input the command to set the environment variable. .PP For \fBWindows\fR, set the environment variable by clicking on the \fBstart\fR button and then right-clicking on \fBMy Computer\fR and selecting \fBProperties\fR. In Properties, click on the \fBAdvanced\fR tab. Then click on the \fBEnvironment Variables\fR button. If you don't see \s-1TW_CLI_LOG\s0 you may add and set it to \s-1ON\s0 of \s-1OFF\s0 by clicking on \fBNew\fR, (or edit an existing one by clicking on \fBEdit\fR). .PP Since the default of Command Logging is \s-1ON\s0, if you wish the turn it off, you could set the environment variable \s-1TW_CLI_LOG\s0 to \s-1OFF\s0. .PP When you cycle power your system, the new environment variable is recorded by Windows and read by \s-1CLI\s0 upon system startup, after which \s-1CLI\s0 will stop logging any new commands associated with the controller. .RE .IP "Log File Location:" .IX Item "Log File Location:" For \fBLinux\fR, \fBFreeBSD\fR, \fBMac \s-1OS\s0\fR, and \fBOpenSolaris\fR, the log file is in the \fI/var/log\fR directory. .PP For \fBWindows Vista\fR and \fBWindows Server 2008\fR, the log file is stored in .PP \&\fI\eProgramData\e3ware\fR .PP Note that ProgramData is a hidden folder by default. To display it in Windows Explorer, enter \fIc:\eProgramData\fR in the location field at the top of the Explorer Window. To make the folder permanently visible, select \&\fBOrganize\-\fR>\fBFolder and Search Options\fR from the Explorer menu, choose the \fBView\fR tab, and select the \fBShow hidden files and folders\fR option in \fBAdvance settings\fR. .PP For previous versions of \fBWindows (\s-1XP\s0, Server 2003, etc)\fR, the log file is stored in .PP \&\fI\eDocuments and Settings\eAll Users\eApplication Data\e3ware\fR .SH "Features" .IX Header "Features" This section lists some of the features that \s-1CLI\s0 supports for the 3ware \s-1RAID\s0 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. .PP Please note that you could consult the \fI3ware \s-1SAS/SATA\s0 \s-1RAID\s0 Software User Guide\fR for more in-depth conceptual information about features that can be used to control your 3ware \s-1RAID\s0 controller as well. .PP 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: .RE .IP "Drive Performance Monitor" .IX Item "Drive Performance Monitor" .RE .PD 0 .IP "Rapid \s-1RAID\s0 Recovery" .IX Item "Rapid RAID Recovery" .RE .IP "User Defined \s-1LUN\s0 Sizing" .IX Item "User Defined LUN Sizing" .RE .IP "Verify" .IX Item "Verify" .RE .IP "Verify \- Advanced" .IX Item "Verify - Advanced" .RE .IP "Verify \- Basic" .IX Item "Verify - Basic" .PD .RS 4 The commands within the subsections below also appear in the \fBPrimary Command Syntax\fR 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. .Sh "Drive Performance Monitor" .IX Subsection "Drive Performance Monitor" Performance monitoring and statistics of the \s-1RAID\s0 controller, as a basis for analysis of performance, may also provide information for qualification and diagnostics. The Drive Performance Monitor of \s-1CLI\s0 supports statistics of queue depths, IOPs, transfer rate, response time for reads/writes, and command reads/writes. .Sp 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. .Sp The types of drive performance statistics supported are organized into five groups: .Sp .Vb 5 \& - instantaneous \& - running average \& - long command times \& - response histogram \& - extended drive statistics .Ve .Sp 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 \s-1FUA\s0 (Force Unit Access), flush commands, and a drive sectors's read, write, and write commands with \s-1FUA\s0. .Sp \&\fBNote:\fR 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. .Sp \&\fB\s-1OPERATION\s0\fR .Sp 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. .Sp \&\fBNote:\fR 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. .Sp 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. .Sp .Vb 34 \& --------------+-----------------------------------+----------------------------------- \& 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. \& --------------+-----------------------------------+----------------------------------- .Ve .Sp \&\fBNote:\fR 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 \s-1ON\s0 or \s-1OFF\s0. If the setting is \s-1ON\s0 and I/O is running, the statistics data will change over time because the measurements are being averaged. If the setting is \s-1OFF\s0, 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 \s-1OFF\s0, the data shown may not be zeros. .Sp Examples of the command's usage are shown below. .Sp To display the configuration of the Drive Performance Monitor of the specified controller (default statistics display is instantaneous data), use command \&\fB/cx show dpmstat\fR. For example: .Sp .Vb 7 \& //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 .Ve .Sp .Vb 11 \& 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 - - - - - .Ve .Sp 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. .Sp To set the Drive Performance Monitor to 'enable' or 'disable', use commands \&\fB/cx set dpmstat=on\fR and \fB/cx set dpmstat=off\fR, respectively. For example: .Sp .Vb 2 \& //localhost> /c0 set dpmstat=off \& Setting Drive Performance Monitoring on /c0 to [off]... Done. .Ve .Sp 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 \fB/cx show dpmstat type=ra\fR. For example: .Sp .Vb 1 \& //localhost> /c0 show dpmstat type=ra .Ve .Sp .Vb 6 \& 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 .Ve .Sp .Vb 11 \& 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 - - - - - .Ve .Sp To display the running average drive statistics of the specified port, use command \fB/cx/px show dpmstat type=ra\fR. For example: .Sp .Vb 1 \& //localhost> /c0/p3 show dpmstat type=ra .Ve .Sp .Vb 4 \& Queue Xfer Resp \& Port Status Unit Depth IOPs Rate(MB/s) Time(ms) \& --------------------------------------------------------------------- \& p3 OK u0 0 435 25.249 2 .Ve .Sp For data associated with commands that have long command times for the specified port, use command \fB/cx/px show dpmstat type=lct\fR. For example: .Sp .Vb 1 \& //localhost> /c0/p3 show dpmstat type=lct .Ve .Sp .Vb 3 \& Port Status Unit \& ------------------------------ \& p3 OK u0 .Ve .Sp .Vb 13 \& 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 .Ve .Sp Note that in addition to the time and date stamps of the commands with the long response times, their corresponding \s-1CDB\s0 or \s-1ATA\s0 Task File is displayed. .Sp For histogram of IOPs grouped together based on response time associated with the specified port, use command \fB/cx/px show dpmstat type=histdata\fR. For example: .Sp .Vb 1 \& //localhost> /c0/p3 show dpmstat type=histdata .Ve .Sp .Vb 3 \& Port Status Unit \& ------------------------------ \& p3 OK u0 .Ve .Sp .Vb 40 \& 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 .Ve .Sp 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. .Sp To clear the running average statistics data of the specified port, use command \fB/cx/px set dpmstat=clear type=ra\fR. For example: .Sp .Vb 2 \& //localhost> /c0/p3 set dpmstat=clear type=ra \& Clearing Port Performance Monitor running average statistics on /c0/p3... Done. .Ve .Sp Please note that this clears the Running Average and Histogram data. .Sp \&\fBNote:\fR 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. .Sp 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: .Sp .Vb 1 \& //localhost> /c0/p3 show dpmstat type=ra .Ve .Sp .Vb 4 \& Queue Xfer Resp \& Port Status Unit Depth IOPs Rate(MB/s) Time(ms) \& --------------------------------------------------------------------- \& p3 OK u0 0 0 0.000 0 .Ve .Sp Note that IOPs, Xfer Rate (transfer rate), and Resp Time (response time) are all zeros. .Sp If I/O traffic to the drive has been stopped, after clearing, a subsequent request to show the histogram data would show, for example: .Sp .Vb 1 \& //localhost> /c0/p3 show dpmstat type=histdata .Ve .Sp .Vb 3 \& Port Status Unit \& ------------------------------ \& p3 OK u0 .Ve .Sp .Vb 26 \& 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 \& : \& : \& : .Ve .Sp To display the extended drive statistics associated with the specified port, use command \fB/cx/px show dpmstat type=ext\fR. For example: .Sp .Vb 2 \& //localhost> /c3/p0 show dpmstat type=ext \& Requested data: Extended Drive Statistics .Ve .Sp .Vb 5 \& Sectors Commands \& ----------------------------- --------------------------------------- \& Port Read Write Write-FUA Read Write Write-FUA Flush \& ------------------------------------------------------------------------------ \& p0 28704384 0 28704384 28704448 0 0 0 .Ve .Sp To display the extended drive statistics associated with the specified controller, as a summary of the drives, use command \fB/cx show dpmstat type=ext\fR. For example: .Sp .Vb 2 \& //localhost> /c3 show dpmstat type=ext \& Extended Drive Statistics for /c3 ... .Ve .Sp .Vb 8 \& 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 .Ve .Sp 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: .Sp .Vb 2 \& //localhost> /c3 show dpmstat type=ext \& Extended Drive Statistics for /c3 ... .Ve .Sp .Vb 8 \& 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 .Ve .Sp 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 \fB/cx/px set dpmstat=clear type=ext\fR. For example: .Sp .Vb 2 \& //localhost> /c3/p0 set dpmstat=clear type=ext \& Clearing Performance Monitor extended drive statistics on /c3/p0 ... Done. .Ve .Sh "Rapid \s-1RAID\s0 Recovery" .IX Subsection "Rapid RAID Recovery" Rapid \s-1RAID\s0 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. .Sp 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 \s-1RAID\-1\s0, \&\s-1RAID\-5\s0, \s-1RAID\-6\s0, \s-1RAID\-10\s0 and \s-1RAID\-50\s0. This feature is not supported over migration. .Sp \&\fB\s-1OPERATION\s0\fR .Sp 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. .Sp .Vb 3 \& /cx add ... rapidrecovery=all|rebuild|disable \& /cx/ux set rapidrecovery=all|rebuild|disable [quiet] \& /cx/ux show rapidrecovery .Ve .Sp If you set this option to \fBall\fR, upon an unclean system shutdown, the Rapid \s-1RAID\s0 Recovery policy will apply to rebuild, initialize, and verify tasks at reboot. If you set this option to \fBrebuild\fR, then only the rebuild task will be applied. If you set it to \fBdisable\fR, 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. .Sp \&\fBNote:\fR Once the Rapid \s-1RAID\s0 Recovery has been \*(L"disabled\*(R" 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. .Sp \&\fBNote:\fR The default setting of Rapid \s-1RAID\s0 Recovery is 'all' for redundant arrays. For non-redundant arrays the default is disabled. .Sp Consider a 9690SA controller with four drives attached. Creating a \s-1RAID\-5\s0 unit with the rapidrecovery attribute set to the \fBall\fR option: .Sp .Vb 1 \& //localhost> /c1 add type=raid5 disk=0:2:3 rapidrecovery=all .Ve .Sp .Vb 7 \& 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. .Ve .Sp Subsequent inquiry of the controller and unit information would show: .Sp .Vb 1 \& //localhost> /c1 show .Ve .Sp .Vb 3 \& Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy \& ------------------------------------------------------------------------------ \& u0 RAID-5 OK - - 64K 298.002 ON ON .Ve .Sp .Vb 6 \& 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 .Ve .Sp .Vb 1 \& //localhost> /c1/u0 show .Ve .Sp .Vb 7 \& 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 .Ve .Sp The created \s-1RAID\-5\s0 unit would be configured with Rapid \s-1RAID\s0 Recovery set to \&\*(L"all\*(R" that the user could see with the 'show" command: .Sp .Vb 2 \& //localhost> /c1/u0 show rapidrecovery \& /c1/u0 Rapid RAID Recovery policy setting = all .Ve .Sp To change the Rapid \s-1RAID\s0 Recovery setting to 'rebuild': .Sp .Vb 2 \& //localhost> /c1/u0 set rapidrecovery=rebuild \& Setting Rapid RAID Recovery policy on /c1/u0 to [rebuild] ... Done. .Ve .Sp 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: .Sp .Vb 5 \& //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. .Ve .Sp If the user replies with \*(L"n\*(R" for No, the command is aborted. .Sp With the quiet option: .Sp .Vb 2 \& //localhost> /c1/u0 set rapidrecovery=disable quiet \& Setting Rapid RAID Recovery policy on /c1/u0 to [disable] ... Done. .Ve .Sp And to see the setting, subsequently: .Sp .Vb 2 \& //localhost> /c1/u0 show rapidrecovery \& /c1/u0 Rapid RAID Recovery policy setting = disable .Ve .Sh "User Defined \s-1LUN\s0 Sizing" .IX Subsection "User Defined LUN Sizing" User Defined \s-1LUN\s0 Sizing, or, Variable \s-1LUN\s0 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 \s-1LUN\s0. This feature allows the user to specify up to four volumes or LUNs in a unit. .Sp You can define the \s-1LUN\s0 sizes for these array types: \s-1RAID\-0\s0, \s-1RAID\-1\s0, \&\s-1RAID\-10\s0, \s-1RAID\-5\s0, \s-1RAID\-50\s0, \s-1RAID\-6\s0 and Single. .Sp To specify Variable \s-1LUN\s0 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. .Sp If the pre-existing related commands are included, the set of \s-1LUN\s0 carve commands are the following: .Sp .Vb 5 \& /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] .Ve .Sp Note that the first command associates with this feature, and the latter four commands have pre\-existed. .Sp While the Variable \s-1LUN\s0 Sizing feature is related to the autocarve feature, they are independent. If autocarve has been set to \s-1ON\s0, 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} \s-1GB\s0 or {1..32} \s-1TB\s0. 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 \s-1ON:\s0 .Sp Autocarve=ON, carvesize=1024GB (1TB) .Sp .Vb 3 \& ------+------+------+------+------+------+------+------+------+------+------- \& 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 . . . \& ------+------+------+------+------+------+------+------+------+------+------- .Ve .Sp If we specify the first four \s-1LUN\s0 volumes to be 2000GB, 500GB, 1024GB, and 700GB, then we have the following: .Sp .Vb 3 \& ------------+---+------+----+-----+------+------+------+------+------+------- \& 2000 500 1024 700 896 1024 1024 1024 1024 1024 . . . \& ------------+---+------+----+-----+------+------+------+------+------+------- .Ve .Sp All numbers are in units of \s-1GB\s0. Note the while the last specified carved size was 700GB, the next carved volume is not 1024GB but, .Sp .Vb 1 \& 1024GB - (remainder of last volume carved) .Ve .Sp Or: .Sp .Vb 1 \& 1024 - 128 = 896 .Ve .Sp 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. .Sp For the add command, at unit creation time the volume sizes could be specified with either the attribute \fBv0=\fR or \fBvol=\fR. With \fBv0\fR only the first \s-1LUN\s0 volume size could be specified. With \fBvol\fR, up to four \s-1LUN\s0 volume sizes may be specified. The input of size is an integer in gigabytes (\s-1GB\s0) and the valid range is [1..32768], the upper limit is 32TB. .Sp If the \fBvol=a:b:c:d\fR attribute is used, each volume is separated by the symbol \fB:\fR in ascending order. That is, the integer closest to \fB=\fR 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. .Sp For example, consider an 8\-port controller with four drives attached. As in the following: .Sp .Vb 1 \& //localhost> show .Ve .Sp .Vb 3 \& Ctl Model Ports Drives Units NotOpt RRate VRate BBU \& ------------------------------------------------------------------------ \& c0 Geroni133/Ap 8 4 0 0 1 1 - .Ve .Sp .Vb 3 \& Encls Slots Drives Fans TSUnits \& ---------------------------------------- \& /c0/e0 4 2 1 1 .Ve .Sp .Vb 1 \& //localhost> /c0 show .Ve .Sp .Vb 2 \& Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy \& ------------------------------------------------------------------------------ .Ve .Sp .Vb 10 \& 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 - - - - .Ve .Sp To create the unit and specify the \s-1LUN\s0 sizes of the first four volumes: .Sp .Vb 1 \& //localhost> /c0 add type=raid5 disk=2-5 vol=100:30:2:45 .Ve .Sp .Vb 3 \& 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. .Ve .Sp After the unit creation, to see the volume sizes, a subsequent \*(L"show\*(R" command for the unit would display: .Sp .Vb 1 \& //localhost> /c0/u0 show .Ve .Sp .Vb 12 \& 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 .Ve .Sh "Verify" .IX Subsection "Verify" The Verify function is among other self-test functions such as Rebuild and Selftest in the \s-1RAID\s0 system. It performs data integraty checks on an array unit based on the unit type. For a \s-1RAID\-1\s0 array, for example, the verification involves checking that both drives contain the exact data; and on a \s-1RAID\-5\s0 array, the parity information is used to verify data integrity. .Sp 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. .Sp \&\fB\s-1SET\s0 \s-1UP\s0\fR .Sp For the \fBVerify\fR function, the following commands are used for the set up: .Sp .Vb 3 \& /cx set verify=enable|disable|1..5 \& /cx add verify=ddd:hh:duration \& /cx del verify=slot_id .Ve .Sp 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. .Sp When a verify background process would initiate and run depends on more than the Schedule itself. The sections below describe this in more detail. .Sp \&\fB\s-1AUTOVERIFY\s0\fR .Sp Related to this Verify function is \fBautoverify\fR. The Autoverify setting lets the \s-1RAID\s0 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 \s-1ON\s0. 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. .Sp Autoverify applies to 9000 series controllers also. .Sp The commands associated with Autoverify are the following: .Sp .Vb 2 \& - /cx/ux set autoverify=on|off \& - /cx/ux show autoverify .Ve .Sp Autoverify is also an attribute that could be set at unit creation. The setting of autoverify is \s-1ON\s0 if Basic Verify (see \fBVerify \- Basic\fR section) is supported, otherwise the default is set to \s-1OFF\s0. .Sp \&\fB\s-1MANUAL\s0 \s-1VERIFY\s0\fR .Sp 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: .Sp .Vb 2 \& /cx/ux start verify \& /cx/ux stop verify .Ve .Sp 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. .Sp \&\fB\s-1VERIFY\s0 \s-1STATUS\s0\fR .Sp Finally, to see the status of the tasks associated with the Verify function, the set of commands for that is the following: .Sp .Vb 4 \& show verify \& /cx show verify \& /cx/ux show verifystatus \& /cx/ux show autoverify .Ve .Sp Here is an example of the show verify command. .Sp .Vb 1 \& //localhost> /c2 show verify .Ve .Sp .Vb 11 \& 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 .Ve .Sp For other examples of the Verify commands, please see the \fBPrimary Command Syntax\fR section of this document. .Sp 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. .Sp .Vb 25 \& -------------+----------------------+------------------------+------------------------ \& 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). \& -------------+----------------------+------------------------+------------------------ .Ve .Sp Please note that the command \fI/cx/ux start verify\fR is associated with Manual Verify only when Verify=Disable. When Verify=Enable, it does not necessarily start the verify task immediately. .Sh "Verify \- Advanced" .IX Subsection "Verify - Advanced" 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: .Sp .Vb 1 \& /cx set verify=advanced|basic|1..5 .Ve .Sp If the system does not support Advanced/Basic Verify, you would get the following error: .Sp .Vb 2 \& //localhost> /c2 set verify=advanced \& Error: (CLI:146) Basic/Advanced Verify is not supported. .Ve .Sp 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. .Sp We will show a setup scenario to demonstrate how the commands are used with respect to this feature. For a \s-1RAID\s0 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. .Sp .Vb 1 \& //localhost> /c3 show .Ve .Sp .Vb 4 \& 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 .Ve .Sp .Vb 6 \& 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 .Ve .Sp First we issue /cx set verify=advanced: .Sp .Vb 2 \& //localhost> /c3 set verify=advanced \& Enabling scheduled verifies on controller /c3 ... Done. .Ve .Sp We could issue a show command to see the default verify schedule: .Sp .Vb 1 \& //localhost> /c3 show verify .Ve .Sp .Vb 11 \& 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 .Ve .Sp 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. .Sp .Vb 2 \& //localhost> /c3 del verify=3 \& Removing scheduled verify slot [3] ... Done. .Ve .Sp Now to add a new background verify task onto the schedule: .Sp .Vb 2 \& //localhost> /c3 add verify=sun:15:4 \& Adding scheduled verify to slot 3 for [Sun, 3:00PM, 4hr(s)] ... Done. .Ve .Sp Now the schedule would show: .Sp .Vb 1 \& //localhost> /c3 show verify .Ve .Sp .Vb 11 \& 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 .Ve .Sp To see the autoverify setting and then set it to \s-1ON\s0 for our \s-1RAID\-5\s0 array: .Sp .Vb 2 \& //localhost> /c3/u0 show autoverify \& /c3/u0 Auto Verify Policy = off .Ve .Sp .Vb 2 \& //localhost> /c3/u0 set autoverify=on \& Setting Auto-Verify Policy on /c3/u0 to [on] ... Done. .Ve .Sp If we issue a start verify to unit /u3: .Sp .Vb 3 \& //localhost> /c3/u0 start verify \& Sending start verify message to /c3/u0 ... Done. \& Unit was not previously initialized. Will be initialized first before verified. .Ve .Sp If we subsequently look at unit /u3 (on Tuesday, 12:30PM): .Sp .Vb 1 \& //localhost> /c3 show .Ve .Sp .Vb 4 \& 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 .Ve .Sp .Vb 6 \& 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 .Ve .Sp Note that the initialize process is starting. .Sp The table below summarizes the settings for Advanced Verify. It describes the interactions of the commands and the corresponding system response. .Sp .Vb 16 \& -------------+----------------------+------------------------+------------------------ \& 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). \& -------------+----------------------+------------------------+------------------------ .Ve .Sp Please note that this is the lower part of the table in the previous section on Verify, with verify=advanced instead of verify=enabled. .Sh "Verify \- Basic" .IX Subsection "Verify - Basic" 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. .Sp 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. .Sp 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: .Sp .Vb 2 \& //localhost> /c2 set verify=advanced \& Error: (CLI:146) Basic/Advanced Verify is not supported for the specified controller. .Ve .Sp The table below summarizes the settings for Basic Verify. It describes the interactions of the commands and the corresponding system response. .Sp .Vb 13 \& -------------+----------------------+------------------------+------------------------ \& 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. | \& -------------+----------------------+------------------------+------------------------ .Ve .Sp To set the background verify task with Basic Verify, specify \fIverify=basic\fR along with the preferred day and time for the verify task to execute: .Sp .Vb 2 \& //localhost> /c3 set verify=basic pref=Fri:23 \& Setting /c3 basic verify preferred start time to [Fri, 11:00PM] ... Done. .Ve .Sp To display the preferred start time and day of the verify task previously set: .Sp .Vb 2 \& //localhost>> /c0 show verify \& /c0 basic verify weekly preferred start: Friday, 11:00PM .Ve .Sp The background verify task will run every Friday starting at 11:00 \s-1PM\s0. .SH "RETURN CODE" .IX Header "RETURN CODE" 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. .SH "ERRATA" .IX Header "ERRATA" .Sh "Meta-Character Warning:" .IX Subsection "Meta-Character Warning:" .RS 4 If you wish to use \s-1CLI\s0 in single command mode (not interactive), make sure to avoid collision with your command interpreter (\s-1OS\s0 shell) by escaping the meta-characters (such as ?, <, >, @, &, *, etc) appropriately with single quote around them. .Sp For example, given the .Sp $ tw_cli /c0 ? .Sp This is a case of single command usage where the user intends to get help on Controller related commands. While this is a valid \s-1CLI\s0 command, but since the arguments to \s-1CLI\s0 are first processed by the shell, then some shells like \fIcsh\fR\|(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 \s-1CLI\s0. .Sp One solutions of this problem can be : .Sp $ tw_cli help /cx .Sp or .Sp $ tw_cli '/c0 ?' .Sp Note: Some of the \s-1OS\s0 shell does not have this problem such as bash. .RE .RE .RS 4 .Sh "Reporting Style" .IX Subsection "Reporting Style" \&\fItw_cli\fR\|(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 \fBinfo\fR) are made available as fast as possible. For example, firmware, \&\s-1PCB\s0, \s-1PCHIP\s0 and similar information have been removed from the info summary report, as this type of information is not frequently needed. .Sp 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 \s-1CLI\s0 yet another \s-1API\s0 (to approach it). .Sp However to accommodate current automations around tw_cli and to ease the migration, the old behavior can still be requested by setting \fB\s-1TW_CLI_STYLE\s0\fR environment variable to \fB\s-1OLD\s0\fR as follows: .Sp .Vb 3 \& If Bash, then "export TW_CLI_STYLE=OLD" \& If csh, then "setenv TW_CLI_STYLE OLD" \& if Windows, then "set TW_CLI_STYLE=OLD" .Ve .Sp This backward compatibility window, will be communicated by official 3ware representatives. .Sh "Initialization Process Control" .IX Subsection "Initialization Process Control" On the 9K series of controllers, the rebuild scheduling controls both rebuild and initialize processes if it is enabled. Currently, \fItw_cli\fR\|(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. .Sh "Environment Variables" .IX Subsection "Environment Variables" \&\s-1TW_CLI_STYLE\s0 setting this variable to \s-1OLD\s0, will provide the old reporting style. \&\s-1TW_CLI_INPUT_STYLE\s0 setting this variable to \s-1OLD\s0, will disable focus feature in the interactive mode. .SH "AUTHOR" .IX Header "AUTHOR" This document was originally written by previous developers of the Command Line Interface (\s-1CLI\s0) software. Since then it has been modified with added terminology and controller model summary information, updated per command usage and output information, and augmented for added support of new commands, features, and controllers, by Marian M. Choy. .SH "SEE ALSO" .IX Header "SEE ALSO" .Vb 4 \& 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 .Ve