tw-cli/tw_cli.8.html
2017-11-10 21:52:38 +01:00

7184 lines
301 KiB
HTML
Executable File

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>3ware Storage Management CLI</title>
<link rev="made" href="mailto:root@localhost" />
</head>
<body style="background-color: white">
<p><a name="__index__"></a></p>
<!-- INDEX BEGIN -->
<ul>
<li><a href="#synopsis">SYNOPSIS</a></li>
<li><a href="#description">DESCRIPTION</a></li>
<li><a href="#primary_command_syntax">Primary Command Syntax</a></li>
<ul>
<li><a href="#shell_object_messages">Shell Object Messages</a></li>
<li><a href="#controller_object_messages">Controller Object Messages</a></li>
<li><a href="#logical_disk_object_messages">Logical Disk Object Messages</a></li>
<li><a href="#port_object_messages">Port Object Messages</a></li>
<li><a href="#phy_object_messages">Phy Object Messages</a></li>
<li><a href="#bbu_object_messages">BBU Object Messages</a></li>
<li><a href="#enclosure_object_messages">Enclosure Object Messages</a></li>
<ul>
<li><a href="#enclosure_element_slot">Enclosure Element Slot</a></li>
<li><a href="#enclosure_element_fan">Enclosure Element Fan</a></li>
<li><a href="#enclosure_element_temperature_sensor">Enclosure Element Temperature Sensor</a></li>
<li><a href="#enclosure_element_power_supply">Enclosure Element Power Supply</a></li>
<li><a href="#enclosure_element_alarm">Enclosure Element Alarm</a></li>
</ul>
</ul>
<li><a href="#help_commands">Help Commands</a></li>
<li><a href="#command_logging">Command Logging</a></li>
<li><a href="#features">Features</a></li>
<ul>
<li><a href="#drive_performance_monitor">Drive Performance Monitor</a></li>
<li><a href="#rapid_raid_recovery">Rapid RAID Recovery</a></li>
<li><a href="#user_defined_lun_sizing">User Defined LUN Sizing</a></li>
<li><a href="#verify">Verify</a></li>
<li><a href="#verify__advanced">Verify - Advanced</a></li>
<li><a href="#verify__basic">Verify - Basic</a></li>
</ul>
<li><a href="#return_code">RETURN CODE</a></li>
<li><a href="#errata">ERRATA</a></li>
<ul>
<li><a href="#metacharacter_warning_">Meta-Character Warning:</a></li>
<li><a href="#reporting_style">Reporting Style</a></li>
<li><a href="#initialization_process_control">Initialization Process Control</a></li>
<li><a href="#environment_variables">Environment Variables</a></li>
</ul>
<li><a href="#author">AUTHOR</a></li>
<li><a href="#see_also">SEE ALSO</a></li>
</ul>
<!-- INDEX END -->
<hr />
<p><code>tw_cli(8)</code> - 3ware Storage Controller Management Command Line Interface
(CLI) manpage / HTML Help Document Version 3.1.</p>
<p>
</p>
<hr />
<h1><a name="synopsis">SYNOPSIS</a></h1>
<pre>
tw_cli Interactive Mode
tw_cli -f file Process from a file
tw_cli command Process single command (batch mode)</pre>
<p>
</p>
<hr />
<h1><a name="description">DESCRIPTION</a></h1>
<p><em>tw_cli(8)</em> is a Command Line Interface Storage Management Software for
3ware ATA RAID Controller(s). It provides controller, logical unit and drive
management. tw_cli can be used in both interactive and batch mode, providing
higher-level API (Application Programming Interface) functionalities.</p>
<p>The CLI prompt indicates the current object in focus, expressed in URI (Universal
Resource Identifier) syntax consisting of a hostname (<em>//hostname</em>), and an object
path (<em>/path/path/object</em>) such as <em>//elvis/c0/u0</em>. User can set the focus to a
particular object by <em>focus URI</em>.</p>
<p>CLI also supports <em>comments</em>. Command lines beginning with <em>#</em> denotes start
of comment. This feature is mostly useful with batch processing via <em>-f script</em>
flag.</p>
<p>CLI uses the following terminology:</p>
<p><strong>Logical Units.</strong> Usually shortened to ``units'', these are block devices presented
to the operating system. A logical unit can be a one-tier, two-tier, or three-tier
arrangement. Spare and Single logical units are examples of one-tier units.
RAID-1 and RAID-5 are examples of two-tier units and
as such will have sub-units. RAID-10 and RAID-50 are examples of three-tier units
and as such will have sub-sub-units.</p>
<p><strong>Port.</strong> 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).</p>
<p><strong>Phy.</strong> Phys are tranceivers that transmit and receive the serial data stream
that flows between the controller and the drives. The 9690SA controller
have 8 phys. These ``controller phys'' are associated with virtual ports (vports)
to establish up to 128 potential connections with the SAS or SATA drives. Each
controller phy can be connected to a single drive, or can be connected through
an expander to additional drives.</p>
<p><strong>VPort.</strong> Connections from the 9690SA and 9750 controllers to drives are referred
to as <em>virtual ports</em>, or vports. A vport indicates the ID of a drive, whether
it is directly connected to the controller, or cascaded through one of more
expanders. The vport, in essense, is a handle in the software to uniquely
identify a drive. The port ID or vport ID allows a drive to be consistently
identified, used and managed in a RAID unit. For dual-ported drives, although
there are two connections to a drive, the drive is still identified with one
vport handle. <strong>Note:</strong> With the controller summay via the command ``show'',
the number of (V)Ports shown may contain two times (2X) the number of drives
(suggesting the dual-ported drive type) even though the (V)Port column of
the summary to the command ``/cx show'' contains only the number of vports
corresponding to the number of drives. This is because the drive is
identified with only one vport handle.</p>
<p><strong>NOTE:</strong> For all practical purposes, hereafter port and vport are used
interchangeably in reference to a drive (or disk). Therefore, unless otherwise
specified, the mention of port implies vport as well. That is, while ``port''
is mentioned to denote a drive, it is implied that for the applicable controller
series, the reference also applies to vport.</p>
<p>CLI supports a set of primary command syntax and a set of legacy command syntax
that is the old or original command syntax. <strong>Note:</strong> The primary command syntax
replaces that legacy command syntax and as such support for legacy commands will
discontinue in the near future.</p>
<p>Please also note that some of the commands listed in this document are qualified
with restrictions of controller type/model support. For example, ``9000 series'' or
``9550SX and higher'' may be next to a command. The following is a summary of the
controller qualified specifications.</p>
<p>Commands with:</p>
<pre>
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.</pre>
<p>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).</p>
<p>Here is a summary of the controllers and their associated support:</p>
<pre>
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
----------------+-------------------------------------------</pre>
<p>Please note that the support items are accumulative down the list, excepted where
noted. Also, CCU (Chassis Control Unit) refers to the JMR enclosure/Sidecar.</p>
<p>This document organizes the CLI command set as different types of Object
Messages, and descriptions and examples are presented for each object message
or command. While some of the system features could be invoked with one
``set'' command and correspondingly displayed with a ``show'' command and as such,
information regarding the feature may be self-contained within the description
of the set command, other features may require or involve a set of commands
that work together and may not be so straight-forward. For these, the command
descriptions may present a fragmented view of the feature as a result. For
an encapsulated view of certain features and their relevant command set, please see
the <strong>Features</strong> section of this document.</p>
<p>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 <strong>Primary Command Syntax</strong> sections, and for the latter please see the
Features sections.</p>
<p>
</p>
<hr />
<h1><a name="primary_command_syntax">Primary Command Syntax</a></h1>
<p>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:</p>
<pre>
Object Message Attributes</pre>
<p>Objects can be shell commands or can specify a controller, logical unit,
port or vport (drive), or battery backup unit (bbu). Messages are commands
sent to the requested objects. It may be a read operation such as for the
command ``show'', or a write operation for the set, delete, add, stop, start,
or remove commands. Attributes specify the values to read or write.
Attributes are either <em>Boolean Attributes</em> or <em>Named Attributes</em>. Value of a Boolean
attribute is deduced by presence. Value of named attributes are
expressed in a ``key = value'' format.</p>
<p>
</p>
<h2><a name="shell_object_messages">Shell Object Messages</a></h2>
<p>Shell Object Messages are commands (a.k.a. methods/messages) that are sent to
the Command Interpreter (a.k.a. Shell/CLI) itself.</p>
<dl>
<dt><strong><a name="item_show"><em>show</em></a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>Typical output looks like:</p>
</dd>
<dd>
<pre>
//localhost&gt; show</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>The output indicates that <em>Controller 0</em> is a 7500 model with 12 Ports, with 8 Drives
detected (attached), total of 3 Units, with one unit in a NotOpt (Not Optimal) state,
a RRate(Rebuild Rate) of 2, VRate(Verify Rate) of '-' (Not Applicable), BBU of '-'
(Not Applicable). Not Optimal refers to any state except OK and VERIFYING. Other
states include INITIALIZING, INIT-PAUSED, REBUILDING, REBUILD-PAUSED, DEGRADED,
MIGRATING, MIGRATE-PAUSED, RECOVERY, INOPERABLE, and UNKNOWN.</p>
</dd>
<dd>
<p>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:</p>
</dd>
<dd>
<pre>
//localhost&gt; show</pre>
</dd>
<dd>
<pre>
Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU
---------------------------------------------------------------------------
c0 G133e/Astor 12 4 1 0 1 1 -</pre>
</dd>
<dd>
<pre>
Encl Slots Drives Fans TSUnits PSUnits
--------------------------------------------------
/c0/e0 4 2 1 1 1</pre>
</dd>
<dd>
<p>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.</p>
</dd>
<p></p>
<dt><strong><a name="item_show_ver"><strong>show</strong> <em>ver</em></a></strong><br />
</dt>
<dd>
This command will show the CLI and API version.
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; show ver
CLI Version = 2.00.03.018
API Version = 2.01.00.004</pre>
</dd>
<p></p>
<dt><strong><a name="item_show_events__5breverse_5d"><strong>show</strong> <em>events</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dt><strong><a name="item_show_aens__5breverse_5d"><strong>show</strong> <em>AENs</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dt><strong><a name="item_show_alarms__5breverse_5d"><strong>show</strong> <em>alarms</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dd>
This command shows the controller alarms or events, also known as AEN
(Asynchronous Event Notification) messages, of all controllers in the
system. The default display shows the most recent alarm at the end or
bottom of the table. The <em>reverse</em> attribute reverses this order and
shows the most recent alarm at the top of the table. For more information
please see '<em>/cx show AENs</em>'.
</dd>
<p></p>
<dt><strong><a name="item_show_diag"><strong>show</strong> <em>diag</em></a></strong><br />
</dt>
<dd>
This command shows the diagnostic information of all controllers in the
system.
</dd>
<p></p>
<dt><strong><a name="item_show_rebuild"><strong>show</strong> <em>rebuild</em></a></strong><br />
</dt>
<dd>
This command displays all rebuild schedules of all the 9000 controllers
in the system.
</dd>
<p></p>
<dt><strong><a name="item_show_selftest"><strong>show</strong> <em>selftest</em></a></strong><br />
</dt>
<dd>
This command displays all self test schedules of all the 9000 controllers
in the system.
</dd>
<p></p>
<dt><strong><a name="item_show_verify"><strong>show</strong> <em>verify</em></a></strong><br />
</dt>
<dd>
This command displays all verify schedules of all the 9000 controllers
in the system.
</dd>
<p></p>
<dt><strong><a name="item_update_fw_3dfilename_with_path__5bforce_5d"><strong>update</strong> <em>fw=filename_with_path</em> [<em>force</em>]</a></strong><br />
</dt>
<dd>
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 <em>/cx update fw=filename_with_path [force]</em> for detail.
</dd>
<p></p>
<dt><strong><a name="item_focus_object"><strong>focus</strong> <em>Object</em></a></strong><br />
</dt>
<dd>
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
</dd>
<dd>
<pre>
//hostname/c0/u0 show</pre>
</dd>
<dd>
<p>Instead, if the focus is set to <em>//hostname/c0/u0</em>, the prompt is changed
automatically to reflect this and the user would only have to type <em>show</em>.
The concept is similar to being in a particular location in a file system and
requesting a listing of the current directory.</p>
</dd>
<dd>
<p><em>object</em> can have the following forms:</p>
</dd>
<dd>
<p><em>//hostname/cx/ux</em> specifies the fully qualified URI of an object on host
<strong>hostname</strong>, controller <strong>cx</strong>, unit <strong>ux</strong>.</p>
</dd>
<dd>
<p><em>//hostname</em> specifies root of host <strong>hostname</strong>. The hostname is the name of
the system where your 3ware RAID controllers are. With current releases, the
hostname here should be always your system's name.</p>
</dd>
<dd>
<p><em>..</em> specifies one level up (the parent object).</p>
</dd>
<dd>
<p><em>/</em> specifies the root at the current focused host.</p>
</dd>
<dd>
<p><em>./obj</em> specifies the next level of the object.</p>
</dd>
<dd>
<p><em>/c0/bbu</em> specifies a relative path with respect to the current focused hostname.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; focus //elvis.3ware.com
//elvis.3ware.com&gt;</pre>
</dd>
<dd>
<pre>
//elvis.3ware.com&gt; focus /c0/u0
//elvis.3ware.com/c0/u0&gt;</pre>
</dd>
<dd>
<pre>
//elvis.3ware.com/c0/u0&gt; focus ..
//elvis.3ware.com/c0&gt;</pre>
</dd>
<dd>
<pre>
//elvis.3ware.com/c0&gt; focus ./u0
//elvis.3ware.com/c0/u0&gt;</pre>
</dd>
<dd>
<pre>
//elvis.3ware.com/c0&gt; focus /
//elvis.3ware.com&gt;</pre>
</dd>
<dd>
<p>Note that <em>focus</em> is available as default. You can also set <em>TW_CLI_INPUT_STYLE=OLD</em>
in the following to disable the feature.</p>
</dd>
<dd>
<pre>
If Bash, then &quot;export TW_CLI_INPUT_STYLE=OLD&quot;
If csh, then &quot;setenv TW_CLI_INPUT_STYLE OLD&quot;
If Windows, then &quot;set TW_CLI_INPUT_STYLE=OLD&quot;</pre>
</dd>
<p></p></dl>
<p>
</p>
<h2><a name="controller_object_messages">Controller Object Messages</a></h2>
<p>Controller Object Messages are commands (a.k.a. methods/messages) that are sent to
an instance of a controller such as <em>/c0</em>.</p>
<dl>
<dt><strong><a name="item__2fcx_show"><em>/cx</em> <strong>show</strong></a></strong><br />
</dt>
<dd>
This command shows summary information on the specified controller <em>/cx</em>. This
report consists of two to three parts: the <strong>Unit Summary</strong> that lists all units
present, the <strong>Port Summary</strong> that lists the ports and disks attached to them,
and if a BBU unit is installed, the <strong>BBU Summary</strong> that shows information on
the BBU.
</dd>
<dd>
<p>The <strong>Unit Summary</strong> section lists the units present with the unit number,
unit type (such RAID 5), and unit status (such as OK, VERIFYING, INITIALIZING,
etc.). The <strong>%RCompl</strong> reports the percent completion of the unit's Rebuild, if
this task is in progress. The <strong>%V/I/M</strong> 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.</p>
</dd>
<dd>
<p><strong>Note</strong>: If a ``*'' appears at the end of the status, there is an error on one of
the drives in the unit. Rescanning the controller will clear the error status
if the condition no longer exists.</p>
</dd>
<dd>
<p>For controller models up to the 9550SX and 9650SE with Release 9.5.1 or
earlier, the <strong>Port Summary</strong> 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.</p>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p><strong>Note</strong>: 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.</p>
</dd>
<dd>
<p>The <strong>BBU Summary</strong> section lists the online state, readiness, and status of
the BBU unit, along with the voltage, temperature, charge capacity expressed
as time remaining in hours, and the BBU's last test date.</p>
</dd>
<dd>
<p>Additional attributes about controllers, units, ports and disks can be obtained
by querying for them directly. See other show sub-commands below.</p>
</dd>
<dd>
<p>Here is the typical output for controller models up to 9550SX and 9650SE with
Release 9.5.1 or earlier:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c2 show</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<pre>
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK OK 241 22-Jun-2004</pre>
</dd>
<dd>
<p>Here is the typical output for the 9750, 9690SA and 9650SE controller with
Release 9.5.2 or later:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p><strong>Note:</strong> The 'Cache' column in the unit summary differ between the older (up to
9550SX and 9650SE with Release 9.5.1 or earlier) and newer (9750, 9690SA and
9650SE with Release 9.5.2 or later) controllers. In the unit summary of the
``older'' controllers, this column shows the state (ON or OFF) of the write cache
only. For the ``newer'' controllers, the 'Cache' column displays the settings of
both the read cache and the write cache. For example:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>In the above example, W denotes that the write cache is enabled, and RiW denotes
that Read Cache Intelligent and the Write Cache are both enabled. If OFF is
shown then all caches are disabled.</p>
</dd>
<dd>
<p>Below is a summary of the possible settings in that column:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p><strong>Note:</strong> If read cache Intelligent is enabled, the features in the Basic mode
are also enabled.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_attribute_attribute__2e_2e_2e"><em>/cx</em> <strong>show</strong> Attribute Attribute ...</a></strong><br />
</dt>
<dd>
This command shows the current setting of the given <em>attribute(s)</em>. 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.
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_driver"><em>/cx</em> <strong>show</strong> <em>driver</em></a></strong><br />
</dt>
<dd>
This command reports the device driver version associated with controller
<em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show driver
/c0 Driver Version = 1.02.00.036</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_model"><em>/cx</em> <strong>show</strong> <em>model</em></a></strong><br />
</dt>
<dd>
This command reports the controller model of controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show model
/c0 Model = 7500-12</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_firmware"><em>/cx</em> <strong>show</strong> <em>firmware</em></a></strong><br />
</dt>
<dd>
This command reports the firmware version of controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show firmware
/c0 Firmware Version = FE9X 3.03.06.X03</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_bios"><em>/cx</em> <strong>show</strong> <em>bios</em></a></strong><br />
</dt>
<dd>
This command reports the BIOS version of controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show bios
/c0 BIOS Version = BG9X 2.01.00.026</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_monitor"><em>/cx</em> <strong>show</strong> <em>monitor</em></a></strong><br />
</dt>
<dd>
This command reports the monitor (firmware boot-loader) version of
controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show monitor
/c0 Monitor Version = BLDR 1.00.00.008</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_serial"><em>/cx</em> <strong>show</strong> <em>serial</em></a></strong><br />
</dt>
<dd>
This command reports the serial number of the specified controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show serial
/c0 Serial Number = F12705A3240009</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_pcb"><em>/cx</em> <strong>show</strong> <em>pcb</em></a></strong><br />
</dt>
<dd>
This command reports the PCB (Printed Circuit Board) revision of the specified
controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show pcb
/c0 PCB Version = Rev3</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_pchip"><em>/cx</em> <strong>show</strong> <em>pchip</em></a></strong><br />
</dt>
<dd>
This command reports the PCHIP (PCI Interface Chip) version of the specified
controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show pchip</pre>
</dd>
<dd>
<pre>
/c0 PCHIP Version = 1.30-33</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_achip"><em>/cx</em> <strong>show</strong> <em>achip</em></a></strong><br />
</dt>
<dd>
This command reports the ACHIP (ATA Interface Chip) version of the specified
controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show achip</pre>
</dd>
<dd>
<pre>
/c0 ACHIP Version = 3.20</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_numports"><em>/cx</em> <strong>show</strong> <em>numports</em></a></strong><br />
</dt>
<dd>
For controller models earlier than the 9690SA, this command reports the port
capacity (number of physical ports) of the specified controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show numports
/c0 Number of Ports = 12</pre>
</dd>
<dd>
<p>For the 9750 and 9690SA controllers, this command reports the connections
and connection capacity of the specified controller <em>/cx</em>. Connections
consist of vports and phys.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 show numports
/c3 Connections = 4 of 128</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_numunits"><em>/cx</em> <strong>show</strong> <em>numunits</em></a></strong><br />
</dt>
<dd>
This command reports the number of units currently managed by the specified
controller <em>/cx</em>. This report does not include off-line units (or removed units).
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show numunits
/c0 Number of Units = 1</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_numdrives"><em>/cx</em> <strong>show</strong> <em>numdrives</em></a></strong><br />
</dt>
<dd>
This command reports the number of drives currently managed by the specified
controller <em>/cx</em>. This report does not include (logically) removed/exported
drives. Also note that physically removed <code>disk(s)</code> will not be detected unless
I/O is performed against the disk. See <strong>/cx/px show smart</strong> for a workaround.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show numdrives
/c0 Number of Drives = 5</pre>
</dd>
<p></p>
<dt><strong><a name="item_spinup"><em>/cx</em> <strong>show</strong> <em>spinup</em> (9000 series)</a></strong><br />
</dt>
<dd>
This command presents the number of concurrent disks spin up at the power on.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show spinup</pre>
</dd>
<dd>
<pre>
/c0 Disk Spinup Policy = 1</pre>
</dd>
<p></p>
<dt><strong><a name="item_ondegrade"><em>/cx</em> <strong>show</strong> <em>ondegrade</em> (9500S only)</a></strong><br />
</dt>
<dd>
This command presents the write cache policy for degraded units. If the ondegrade
policy is <strong>Follow Unit Policy</strong>, a unit write cache policy stays the same when the
unit becomes degraded. If the ondegrade policy is <strong>off</strong>, a unit cache policy
will force to be off when the unit becomes degraded.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show ondegrade
/c0 Cache on Degraded Policy = Follow Unit Policy</pre>
</dd>
<p></p>
<dt><strong><a name="item_stagger"><em>/cx</em> <strong>show</strong> <em>stagger</em> (9000 series)</a></strong><br />
</dt>
<dd>
This command presents the time delay between each group of spinups at the power on.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show stagger
/c0 Spinup Stagger Time Policy (sec) = 2</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set stagger=nn
/cx set spinup=nn
/cx show spinup</pre>
</dd>
<p></p>
<dt><strong><a name="item_autocarve"><em>/cx</em> <strong>show</strong> <em>autocarve</em> (9550SX and higher)</a></strong><br />
</dt>
<dd>
This command shows the Auto-Carving policy. If the policy is on, all
newly created or migrated units larger than carvesize will be automatically
carved into multiples of carvesize volumes and 1 remainder volume.
Each volume can be treated as an individual disk with its own file system.
The default carvesize is 2 TB.
</dd>
<dd>
<p>This feature is useful for operating systems limited to 2 TB filesystems.
For 64-bit OS users, there is no need to set the policy to be ``on''
unless users want to have multiple smaller volumes to the OS.
For 32-bit OS users, it is recommended to keep the policy on unless users
know their OS supports more than 2 TB disk devices.</p>
</dd>
<dd>
<p>When autocarve policy is off, all the new unit creation consists of one
single volume.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show autocarve
/c0 Auto-Carving Policy = on</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set autocarve=&lt;on|off&gt;
/cx set carvesize=&lt;1024..32768&gt;
/cx show carvesize`</pre>
</dd>
<p></p>
<dt><strong><a name="item_carvesize"><em>/cx</em> <strong>show</strong> <em>carvesize</em> (9550SX and higher)</a></strong><br />
</dt>
<dd>
This command shows the carvesize that Auto-Carving policy needs. The
carve size is between 1024 to 32768 GB (i.e., 1TB-32TB). Default carvesize
is 2048 GB (i.e., 2TB). See ``<em>/cx</em> <strong>show</strong> <em>autocarve</em>'' command above
for details.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show carvesize
/c0 Auto-Carving Size = 2000 GB</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_memory"><em>/cx</em> <strong>show</strong> <em>memory</em></a></strong><br />
</dt>
<dd>
This command presents the size of the memory installed on the controller.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show memory
/c0 Available Memory = 112MB</pre>
</dd>
<p></p>
<dt><strong><a name="item_ctlbus"><em>/cx</em> <strong>show</strong> <em>ctlbus</em> (9550SX and higher)</a></strong><br />
</dt>
<dd>
This command presents the controller host bus type, bus speed and bus width.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show ctlbus</pre>
</dd>
<dd>
<pre>
/c0 Controller Bus Type = PCIX
/c0 Controller Bus Width = 64 bits
/c0 Controller Bus Speed = 133 Mhz</pre>
</dd>
<p></p>
<dt><strong><a name="item_autorebuild"><em>/cx</em> <strong>show</strong> <em>autorebuild</em> (9550SX and higher)</a></strong><br />
</dt>
<dd>
This command shows the Auto-Rebuild policy of the specified controller. If there
is a degraded unit and the policy is set to ON, the controller firmware will choose
drives in the following order of priority, for a drive candidate to perform the
rebuild operation:
</dd>
<dd>
<p>1. Smallest usable capacity spare.</p>
</dd>
<dd>
<p>2. Smallest usable unconfigured drive.</p>
</dd>
<dd>
<p>3. Smallest usable capacity failed drive.</p>
</dd>
<dd>
<p>If the policy is set to OFF, spare drives are the only candidates for an
automatic rebuild operation.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show autorebuild
/c0 Auto-Rebuild Policy = on</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set autorebuild=&lt;on|off&gt;</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_dpmstat__5btype_3dinst_7cra_5d__289550s"><em>/cx</em> <strong>show</strong> <em>dpmstat</em> [type=inst|ra] (9550SX and higher)</a></strong><br />
</dt>
<dt><strong><a name="item__2fcx_show_dpmstat__5btype_3dinst_7cra_7cext_5d__2"><em>/cx</em> <strong>show</strong> <em>dpmstat</em> [type=inst|ra|ext] (9650SE and higher)</a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>The optional 'type' in the command specifies which statistics would be
displayed. The options are either: <strong>inst</strong> for Instantaneous, <strong>ra</strong> for
Running Average, and <strong>ext</strong> 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'.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /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</pre>
</dd>
<dd>
<pre>
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 - - - - -</pre>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p>Also, for examples of other statistic data types, please see the 'Features'
section.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_unitstatus"><em>/cx</em> <strong>show</strong> <em>unitstatus</em></a></strong><br />
</dt>
<dd>
This command presents a list of units, their types, capacity and status
currently managed by the specified controller <em>/cx</em>.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c2 show unitstatus</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_allunitstatus"><em>/cx</em> <strong>show</strong> <em>allunitstatus</em></a></strong><br />
</dt>
<dd>
This command presents a count of Total and Not Optimal units managed by the
specified controller <em>/cx</em>. See <a href="#shell_object_messages">Shell Object Messages</a> for more on Not
Optimal definition.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show allunitstatus</pre>
</dd>
<dd>
<pre>
/c0 Total Optimal Units = 2
/c0 Not Optimal Units = 0</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_drivestatus"><em>/cx</em> <strong>show</strong> <em>drivestatus</em></a></strong><br />
</dt>
<dd>
This command presents a list of drives, port assignment, vendor signature, size,
status, and unit membership/affiliation.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 show drivestatus</pre>
</dd>
<dd>
<pre>
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 - - - -</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_all"><em>/cx</em> <strong>show all</strong></a></strong><br />
</dt>
<dd>
This command shows the current setting of all attributes.
</dd>
<p></p>
<dt><strong><a name="item__2fcx_add_type_3d_3craidtype_3e_disk_3d_3cp_3a_2dp"><em>/cx</em> <strong>add</strong> type=&lt;RaidType&gt; disk=&lt;p:-p&gt; [stripe=size] [noscan]
[group=&lt;3|4|5|6|7|8|9|10|11|12|13|14|15|16&gt;] [nocache|nowrcache]
[nordcache|rdcachebasic] [autoverify|noautoverify] [noqpolicy] [ignoreECC] [name=string]
[storsave=&lt;protect|balance|perform&gt;] [v0=n|vol=a:b:c:d]
[rapidrecovery=all|rebuild|disable]</a></strong><br />
</dt>
<dd>
This command allows you to add a new unit or create a unit on the specified
controller <em>/cx</em>, of type <em>RaidType</em>, optional stripe size of <em>Stripe</em>,
using one or many disks specified by <em>disk=p:-p</em>. By default the host
operating system will be informed of the new block device and write cache
is enabled. In case of RAID-50, you can also specify the layout of the unit
by specifying the number of disks per disk group with <em>group=3|4|5|6|7|8</em>
attribute.
</dd>
<dd>
<p>Upon the success of the new unit creation, a unique serial number is also
assigned to the new unit. Please refer to commands <em>/cx/ux show serial</em>
for checking.</p>
</dd>
<dd>
<p>Please Note:
1) The default of the unit creation sets write cache to ``on'' for performance
reasons. However, if there is no BBU available for the controller, a warning
is sent to standard error.
2) The default drive queuing policy is enabled, unless it is specifically set
to disable queuing by specifing <em>noqpolicy</em>.
3) The <em>noqpolicy</em> attribute is not applicable to the ``spare'' unit. Specifying
the noqpolicy attribute returns an error.
4) The [v0=n|vol=a:b:c:d] option is not applicable to type=single.</p>
</dd>
<dd>
<p>Since this command is by far the richest command, it deserves more details.</p>
</dd>
<dd>
<p><strong>/cx</strong> is the controller name as in /c0, /c1, etc.</p>
</dd>
<dd>
<p><strong>type=RaidType</strong> consists of logical unit type as in <strong>raid0</strong>, <strong>raid1</strong>,
<strong>raid5</strong>, <strong>raid10</strong>, <strong>raid50</strong>, <strong>single</strong>, <strong>spare</strong>, and <strong>raid6</strong> (9650SE
and higher only).</p>
</dd>
<dd>
<p>For example:
</p>
</dd>
<dd>
<pre>
type=raid50</pre>
</dd>
<dd>
<p>The following table illustrates supported types and controller models.</p>
</dd>
<dd>
<pre>
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| | | | | | | | | |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+</pre>
</dd>
<dd>
<p><strong>disk=p:-p</strong> 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 <strong>``:''</strong> or <strong>``-''</strong> as port index separators.
A dash indicates a range and can be mixed with ``:''. For example
<strong>disk=0:1:2-5:9:12</strong> indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12.</p>
</dd>
<dd>
<p><strong>stripe=size</strong> consists of the stripe size to be used. The following
table illustrates the supported and applicable stripes on unit types and
controller models. Stripe size of units are in KB (kilobytes).</p>
</dd>
<dd>
<pre>
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 | | | |
------+---------+-------+-------+-------+--------+--------+-------+-------+--------+</pre>
</dd>
<dd>
<p><strong>group=3|4|5|6|7|8|9|10|11|12|13|14|15|16</strong> consists of the number of disks per group
for a Raid 50 type. <strong>Note:</strong> This attribute can only be used when type=raid50. Also,
group=13-16 is applicable to the 9690SA and 9750 controllers only.</p>
</dd>
<dd>
<p>Recall that a RAID-50 is a multi-tier array. At the most bottom layer,
N number of disks per group are used to form the RAID-5 layer. These
RAID-5 arrays are then integrated into a RAID-0. This attribute allows
you to specify the number of disks in the RAID-5 level. Valid values
are 3, 4, 5, 6, 7 and 8.</p>
</dd>
<dd>
<p>Note that a sufficient number of disks are required for a given pattern or
disk group. For example, given 6 disks, specifying 3 will create two RAID-5.
However given 12 disks, specifying 3 will create four RAID-5 under the RAID-0
level. Given 6 disks and grouping of 6 is not allowed, as you'll basically
be creating a RAID-5.</p>
</dd>
<dd>
<p>The default group varies based on number of disks. For 6 &amp; 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.</p>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p><strong>noscan</strong> attribute instructs CLI not to notify OS of creation of the new unit.
By default CLI will inform the OS. One application of this feature is to avoid
the OS from creating block special devices such as /dev/sdb and /dev/sdc as some
implementations might create naming fragmentation and creating a moving target.</p>
</dd>
<dd>
<p><strong>nocache</strong> or <strong>nowrcache</strong> attribute instructs CLI to disable the write cache
on the newly created unit. Enabling the write cache increases performance at
the cost of high-availability. No caching is recommended when no BBU or UPS
is installed. The system default for the write cache is enable. If a BBU or
UPS is not installed, to avoid possibility of data loss in the event of sudden
power loss, it is recommended that nocache or nowrcache be specified.</p>
</dd>
<dd>
<p><strong>nordcache</strong> attribute instructs CLI to disable the read cache on the newly
created unit. Enabling the read cache increases performance. The <strong>rdcachebasic</strong>
attribute instructs CLI to set the read cache mode on the newly created unit
to <em>Basic</em>. Please note that it is not necessary to include any read cache
attribute if you wish to select the <em>Intelligent</em> mode of Read Cache, since
the system default is Read Cache Intelligent. See ``/cx/ux set rdcache'' for
more information.</p>
</dd>
<dd>
<p><strong>autoverify|noautoverify</strong> 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 <em>/cx/ux set autoverify</em> command section of this document.
This feature is not supported on controller models 7000/8000. For the 9650SE,
9690SA, and 9750 controllers that support Basic Verify, autoverify will be set
to ON by default for the new unit to be created. For other 9000 series controllers
that do not support Basic Verify, autoverify is set to OFF by default for the new
unit. The following table should help clarify regarding the defaults:</p>
</dd>
<dd>
<pre>
---------------------+--------------------+----------------------
&quot;ADD&quot; COMMAND | 9550SX AND HIGHER | 9650SE AND HIGHER
ATTRIBUTE | (No BV support) | (has BV support)
---------------------+--------------------+----------------------
None specified | |
(i.e., use default) | autoverify = OFF | autoverify = ON
---------------------+--------------------+----------------------
autoverify | Enables AutoVerify |
| autoverify = ON | No effect*
---------------------+--------------------+----------------------
noautoverify | | Enables AutoVerify
| No effect* | autoverify = ON
---------------------+--------------------+----------------------
*No effect means that, issuing the add command attribute of that row would
be the same as not issuing any attribute and using the default.</pre>
</dd>
<dd>
<p><strong>Note</strong>: while there is no reason to issue both <em>autoverify</em> and <em>noautoverify</em>
together at unit creation, CLI allows you to do so. Keep in mind however, that
in this case, only the last value specified would be used. That is, for
example, if you specified the command '/c0 add type=raid5 disk=0-2 autoverify
noautoverify', then you are essentially specifying that 'autoverify=OFF' for /c0.</p>
</dd>
<dd>
<p><strong>noqpolicy</strong> attribute instructs CLI to disable the qpolicy (drive queuing) on the
newly created unit. The default qpolicy is <em>on</em> (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 <em>noqpolicy</em> for spare returns an error.</p>
</dd>
<dd>
<p><strong>ignoreECC</strong> attribute enables the ignoreECC/OverwriteECC attribute on the unit
that is to be created. For more details on this feature, refer to <em>/cx/ux set</em>
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.</p>
</dd>
<dd>
<pre>
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 | | | | | | | | | |
--------+-------+-------+-------+-------+--------+------+-------+--------+--------+</pre>
</dd>
<dd>
<p><strong>name=string</strong> attribute allows user to name the new unit. The maximum characters
allowed for the string are 21. No space is allowed within the string. If user likes
to use some special characters which the OS command shell reserves such as '&lt;', '&gt;',
'!', and '&amp;', 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 <em>/cx/ux set name=sting</em> for changing the
name and <em>/cx/ux show name</em> for checking.</p>
</dd>
<dd>
<p><strong>storsave=protect|balance|perform</strong> 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 <em>/cx/ux set storsave=protect|balance|perform</em> for detail.</p>
</dd>
<dd>
<p>Either the <strong>v0=n</strong> or <strong>vol=a:b:c:d</strong> attribute may be used to set the size of the
first volume or (up to) the first 4 volumes of the new unit, respectively. The
first volume may, but not necessarily, be the boot LUN. The <code>value(s)</code> should be
positive <code>integer(s)</code> in units of gigabytes (GB). Zero (0) is an invalid LUN
size input value. The upper user input limit is 32TB. Note that there
are two ways to set the first volume, as either v0=n or vol=n would have the
same effect.</p>
</dd>
<dd>
<p><strong>Note:</strong> If the total size of the specified volumes (up to 4) exceeds the
size of the array, the <code>volume(s)</code> of <code>size(s)</code> that exceeded the array boundary
will not be carved.</p>
</dd>
<dd>
<p>Example (RAID-5 being created with the first volume size set to 10 GB):</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0 add type=raid5 disk=2-5 v0=10</pre>
</dd>
<dd>
<pre>
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.</pre>
</dd>
<dd>
<p>After the unit creation, a subsequent ``show'' command for the unit would show
the volume sizes:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c0/u0 show</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>Example (RAID-0 being created with the volume sizes set to 45, 20, 50, and
12 GB):</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 add type=raid0 disk=0-1 vol=45:20:50:12</pre>
</dd>
<dd>
<pre>
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.</pre>
</dd>
<dd>
<p>After the unit creation, a subsequent ``show'' command for the unit would show
the volume sizes:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3/u0 show</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>The attribute <strong>rapidrecovery</strong> specifies the Rapid RAID Recovery setting for
the unit to be created. Rapid RAID Recovery can speed up the rebuild
process, and it can speed up the initialize and verify tasks for redundant
arrays in the RAID system upon the event of an unclean system shutdown.
This feature allows for expedited boot-up time in the event of an unclean
shutdown. Setting this option to <em>all</em> applies the policy to the rebuild,
initialize and verify tasks at reboot. Setting it to <em>rebuild</em> applies the
policy to the rebuild tasks only. If the policy is set to <em>disable</em>, then
none of the tasks would be sped up.</p>
</dd>
<dd>
<p><strong>Note:</strong> 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.</p>
</dd>
<dd>
<p><strong>Note:</strong> This attribute is for controller models 9750, 9690SA and 9650SE (with
supporting firmware), and is for redundant arrays only. In addition,
Rapid RAID Recovery is not supported over migration.</p>
</dd>
<dd>
<p><strong>Note:</strong> The default setting of Rapid RAID Recovery is 'all' for redundant
arrays. For non-redundant arrays the default is disabled.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_rescan__5bnoscan_5d"><em>/cx</em> <strong>rescan</strong> [<em>noscan</em>]</a></strong><br />
</dt>
<dd>
This command instructs the controller to rescan all ports and reconstitute
all units. The controller will update its list of ports (attached disks), and visits
every DCB (Disk Configuration Block) in order to re-assemble its view and
awareness of logical units. Any newly found <code>unit(s)</code> or <code>drive(s)</code> will be listed.
<em>noscan</em> is used to not inform the OS of the unit discovery. Default is to inform
the OS.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 rescan</pre>
</dd>
<dd>
<pre>
Rescanning controller /c1 for units and drives ...Done.
Found following unit(s): [/c1/u3].
Found following drive(s): [/c1/p7, /c1/p8].</pre>
</dd>
<dd>
<p>Note: Does not import non-JBOD on 7000/8000 models.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_commit"><em>/cx</em> <strong>commit</strong></a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>Typical application of this feature is when an application is using a given
unit in raw mode (such as databases) and user would like to shutdown the
host (Including UPS post failure automations). This command can then expedite
the process by instructing the controller to finish pending requests, clear
DCB's in-transaction flag as we are going down.</p>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p>This command only applies to Windows operating system.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_flush"><em>/cx</em> <strong>flush</strong></a></strong><br />
</dt>
<dd>
This command allows you to flush the write cache on all units associated with
the <em>/cx</em> controller
</dd>
<p></p>
<dt><strong><a name="item__2fcx_update_fw_3dfilename_with_path__5bforce_5d"><em>/cx</em> <strong>update</strong> <em>fw=filename_with_path</em> [<em>force</em>]</a></strong><br />
</dt>
<dd>
This command allows the download of the specified firmware image to the corresponding
controller. This command is for 9000 series controllers only.
</dd>
<dd>
<p><strong>fw=filename_with_path</strong> attribute allows the user to specify the firmware image file
name along with its path. Please note that <em>filename_with_path</em> could not have
spaces in the directory names of its path (as Windows would allow).</p>
</dd>
<dd>
<p>The new image specified by <em>filename_with_path</em> 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.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c2 update fw=/tmp/prom0006.img</pre>
</dd>
<dd>
<pre>
Warning: Updating the firmware can render the device driver and/or
management tools incompatible. Before you update the firmware,
it is recommended that you:</pre>
</dd>
<dd>
<pre>
1) Back up your data.</pre>
</dd>
<dd>
<pre>
2) Make sure you have a copy of the current firmware image so that
you can roll back, if necessary.</pre>
</dd>
<dd>
<pre>
3) Close all applications.</pre>
</dd>
<dd>
<pre>
Examining compatibility data from firmware image and /c2 ... Done.</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<pre>
Current firmware version is the same as the new firmware.
Recommendation: No need to update.</pre>
</dd>
<dd>
<pre>
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.</pre>
</dd>
<dd>
<p>The <strong>force</strong> 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.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_events__5breverse_5d"><em>/cx</em> <strong>show</strong> <em>events</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dt><strong><a name="item__2fcx_show_aens__5breverse_5d"><em>/cx</em> <strong>show</strong> <em>AENs</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dt><strong><a name="item__2fcx_show_alarms__5breverse_5d"><em>/cx</em> <strong>show</strong> <em>alarms</em> [<em>reverse</em>]</a></strong><br />
</dt>
<dd>
Asynchronous events or AENs (Asynchronous Event Notifications) of the controller,
also known as 'controller alarms', are originated by firmware and captured by
their respective device drivers. These events are kept in a finite queue inside
the kernel, awaiting extraction by user space programs such as CLI and/or 3DM2.
These events reflect messages of varying severity levels. The levels range
in order of severity: INFO, WARNING, and ERROR, respectively.
</dd>
<dd>
<p>Controller Events or Alarms generated on the 7000/8000 series controllers do not
have dates, as such a dash ('-') indicating 'read not-applicable' is displayed
in the ``Date'' column. Also, with the 7000/8000 series controllers, the event
message contains the severity as well, hence the ``Severity'' column shows a '-'
also.</p>
</dd>
<dd>
<p>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 <em>reverse</em>. With this the most recent AEN message
would appear at the top of the table.</p>
</dd>
<dd>
<p>Typical output looks like:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show events</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_diag"><em>/cx</em> <strong>show</strong> <em>diag</em></a></strong><br />
</dt>
<dd>
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 ID, etc.), followed by diagnostic
information of the controller.
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p>Typical output (for model 9650SE/higher and running 9.5.3/higher release)
looks like the following:</p>
</dd>
<dd>
<pre>
//dhcp-147-145-95-103&gt; /c2 show diag</pre>
</dd>
<dd>
<pre>
### 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</pre>
</dd>
<dd>
<pre>
==========================================================================
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
--------------------------------------------------------------------------</pre>
</dd>
<dd>
<pre>
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 (\uffffC): 23
Link Speed: Supported=0x3 (1.5 Gbs to 3.0 Gbs) Current=0x2 (3.0 Gbs)
Spndle Spd: 7200
:
:
:
:</pre>
</dd>
<dd>
<p>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 od(1).</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
$ tw_cli /c0 show diag &gt; diag.txt</pre>
</dd>
<dd>
<p>Please note that some characters may not be printable or may not render
correctly.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_phy"><em>/cx</em> <strong>show</strong> <em>phy</em></a></strong><br />
</dt>
<dd>
This command is for the 9650SE with Release 9.5.2 or later, and the 9690SA
or newer controllers only. It reports a list of phys with related information
for the specified controller. The 'Device Type' column indicates whether
the connected device is an enclosure, or a drive of type SATA or SAS. The
'Device' column is the device ID or handle. There are three 'Link Speed'
columns: 'Supported' denotes the link speed capability of the phy/device,
'Enable' denotes the current link speed setting, and 'Control' denotes the
link control setting.
</dd>
<dd>
<p>looks like the following
Example of 9690SA-8E connected to drives in an enclosure:</p>
</dd>
<dd>
<pre>
//localhost&gt; /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</pre>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<p>Example of 9690SA-8I with directly attached drives:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 show phy</pre>
</dd>
<dd>
<pre>
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 - - - - - -</pre>
</dd>
<dd>
<p><strong>Note:</strong> There is no ``/cx set phy'' command. Moreover, the only changeable
setting for phy is link speed. To change the link speed, see the
<em>/cx/phyx set link</em> command. To see information for an individual
phy only, use <em>/cx/phyx show</em>. These commands are in the ``Phy Object
Messages'' section.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_rebuild"><em>/cx</em> <strong>show</strong> <em>rebuild</em></a></strong><br />
</dt>
<dd>
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 <em>add</em>, <em>del</em>, <em>show</em> and <em>set</em>. Background tasks have
a slot id, start day, hour, duration, and status attributes.
</dd>
<dd>
<p>Rebuild activity attempts to (re)synchronize all members of redundant units
such as RAID-1, RAID-10, RAID-5 and RAID-50. Rebuilds can be started manually
or automatically if a spare has been defined. Scheduled rebuilds will take
place during the scheduled window, if enabled.</p>
</dd>
<dd>
<p>This command displays the current rebuild background task schedule as
illustrated below.</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 show rebuild</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>The status of <em>disabled</em> denotes that the controller will not use the scheduled
time slots.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_rebuildmode"><em>/cx</em> <strong>show</strong> <em>rebuildmode</em></a></strong><br />
</dt>
<dd>
This command shows the current rebuild mode setting of the specified controller.
The rebuild mode has two settings: ``Adaptive'' and ``Low latency''.
</dd>
<dd>
<p>The Adaptive setting tells the controller to keep its current background activity
task policy and it is the default. The Low Latency setting ``throttles'' the
background task and allow host Reads to complete, thus improves performance in
the situation when a rebuild background task is active with the task rate has
been set to high (that is, low I/O rate).</p>
</dd>
<dd>
<p>This command is associated with the rebuild task rate, please also see /cx show
rebuildrate.</p>
</dd>
<dd>
<p>This command is supported on the 9650SE controller with Release 9.5.2 or later
and for the 9690SA and higher model controllers.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show rebuildmode
/c1 Rebuild background task mode = Low Latency</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set rebuildmode=&lt;adaptive|lowlatency&gt;
/cx set rebuildrate=&lt;1..5&gt;
/cx show rebuildrate</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_rebuildrate"><em>/cx</em> <strong>show</strong> <em>rebuildrate</em></a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>This task rate is of the range [1..5], where 5 denotes the setting of fastest
background task and slowest I/O, as follows:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>This command applies to the 7000, 8000, and 9000 models controllers.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show rebuildrate
/c1 Rebuild background task rate = 4 (faster rebuild; slower I/O)</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set rebuildrate=&lt;1..5&gt;
/cx set rebuildmode=&lt;adaptive|lowlatency&gt;
/cx show rebuildmode</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_verify"><em>/cx</em> <strong>show</strong> <em>verify</em></a></strong><br />
</dt>
<dd>
Verify is one of the supported background tasks, and this command displays the
current verify schedule.
</dd>
<dd>
<p>For the 9650SE and newer RAID controllers, the Verify Task Schedule can be either
<strong>basic</strong> or <strong>advanced</strong> (For details about the two types and the associated
commands, please see the 'Features' section.) The basic Verify Task Schedule
sets a weekly day and time for verification to occur, and is designed to be
used with unit auto-verify. The advanced Verify Task Schedule provides
more control, and is equivalent to the Verify Task Schedule available for
9550SX and earlier RAID controllers.</p>
</dd>
<dd>
<p>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 <em>add</em>, <em>del</em>, <em>show</em> and <em>set</em>. The task
schedule has a slot id, start-day-time, duration, and status attributes. Rebuild
follow similar background task schedules.</p>
</dd>
<dd>
<p>For details about setting up a schedule for verify tasks, see <em>/cx set verify</em>.</p>
</dd>
<dd>
<p>Verify activity attempts to verify all units based on their unit type. Verifying
RAID-1 involves checking that both drives contain the exact data. On RAID-5 and
RAID-6, the parity information is used to verify data integrity. RAID-10 and 50
are composite types and follow their respective array types. On the 9000 series,
non-redundant units such as RAID-0, JBOD, single, and spare, are also verified
(by reading and reporting un-readable sectors).</p>
</dd>
<dd>
<p>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.</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 show verify</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>The status of <em>disabled</em> denotes that the controller will not use the scheduled
time slots.</p>
</dd>
<dd>
<p>Example 2:
For the 9650SE and newer controllers, if the <strong>basic</strong> Verify Task Schedule is
selected, the show verify command displays the following:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show verify
/c1 basic verify weekly preferred start: Friday 12:00am</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_verifymode"><em>/cx</em> <strong>show</strong> <em>verifymode</em></a></strong><br />
</dt>
<dd>
This command shows the current verify mode setting of the specified controller.
The verify mode has two settings: ``Adaptive'' and ``Low latency''.
</dd>
<dd>
<p>The Adaptive setting tells the controller to keep its current background activity
task policy and it is the default. The Low Latency setting ``throttles'' the
background task and allow host Reads to complete, thus improves performance in the
situation when a verify background task is active with the task rate has been set
to high (that is, low I/O rate).</p>
</dd>
<dd>
<p>This command is associated with the verify task rate, please also see /cx show
verifyrate.</p>
</dd>
<dd>
<p>This command is supported on the 9650SE controller with Release 9.5.2 or higher,
and for the 9690SA and higher model controllers.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show verifymode
/c1 Verify background task mode = Low Latency</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set verifymode=&lt;adaptive|lowlatency&gt;
/cx set verifyrate=&lt;1..5&gt;
/cx show verifyrate</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_verifyrate"><em>/cx</em> <strong>show</strong> <em>verifyrate</em></a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>This task rate is of the range [1..5], where 5 denotes the setting of fastest
background task and slowest I/O, as follows:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>This command applies to the 7000, 8000, and 9000 models controllers.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 show verifyrate
/c1 Verify background task rate = 4 (faster rebuild; slower I/O)</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx set verifyrate=&lt;1..5&gt;
/cx set verifymode=&lt;adaptive|lowlatency&gt;
/cx show verifymode</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_show_selftest"><em>/cx</em> <strong>show</strong> <em>selftest</em></a></strong><br />
</dt>
<dd>
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
<em>add</em>, <em>del</em>, <em>show</em> and <em>set</em> a task. Background tasks have attributes of
slot id, start-day-time, duration, and status.
</dd>
<dd>
<p>The selftest that would be performed is called SMART (Self Monitoring Analysis and Reporting).
The SMART selftest instructs the controller to check certain SMART supported thresholds
by the disk vendor. An AEN is logged to the alarms table if a drive reports a SMART
failure. The failing drive should be replaced if this error occurs.</p>
</dd>
<dd>
<p>This command displays the current selftest background task schedule as illustrated below.</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 show selftest</pre>
</dd>
<dd>
<pre>
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</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_add_rebuild_3dddd_3ahh_3aduration"><em>/cx</em> <strong>add</strong> <em>rebuild=ddd:hh:duration</em></a></strong><br />
</dt>
<dd>
This command registers a new background rebuild task to the schedule, for execution
on the day of <em>ddd</em> (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at the
hour of <em>hh</em> (range 0 .. 23), for a duration of <em>duration</em> (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.
</dd>
<dd>
<p>For ``rebuild'' background task description, see command <strong>/cx show rebuild</strong>.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 add rebuild=sun:16:3
Adding scheduled rebuild to slot 7 for [Sun, 4:00PM, 3hr(s)] ... Done.</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_add_verify_3dddd_3ahh_3aduration"><em>/cx</em> <strong>add</strong> <em>verify=ddd:hh:duration</em></a></strong><br />
</dt>
<dd>
This command registers a new task slot to the Verify Task Schedule on the day
of <em>ddd</em> (where <em>ddd</em> is Sun, Mon, Tue, Wed, Fri, or Sat), at the hour of <em>hh</em>
(range 0..23), for a duration of <em>duration</em> (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.
</dd>
<dd>
<p><strong>Note:</strong> 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'.</p>
</dd>
<dd>
<p><strong>Note:</strong> If you have a 9650SE with Release 9.5.2 or later, or a 9690SA or newer
controller, you may use the simpler <strong>basic</strong> verify schedule with the command
<em>/cx set verify=basic</em>. Simply specify a weekly day and time and make sure
that the auto-verify policy is set to ON for your RAID units. For more information
please see '/cx set verify=basic' or the section on Basic Verify in the
Features section of this document.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 add verify=sun:23:2
Adding scheduled verify to slot 3 for [Sun, 11:00PM, 2hr(s)] ... Done.</pre>
</dd>
<dd>
<p>In the above example, a verify task slot is added to the schedule to be
executed in the 2-hour duration time window on Sundays at 11:00 PM.</p>
</dd>
<dd>
<p><strong>Note:</strong> Use the <em>/cx/ux set autoverify=on</em> command to turn on autoverify for
each unit you wish to follow the schedule.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_add_selftest_3dddd_3ahh"><em>/cx</em> <strong>add</strong> <em>selftest=ddd:hh</em></a></strong><br />
</dt>
<dd>
This command registers a new background <em>selftest</em> task to the schedule, for
executed on day of <em>ddd</em> (where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat),
at hour of <em>hh</em> (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.
</dd>
<dd>
<p>For ``selftest'' background task description, see command <strong>/cx show selftest</strong>.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 add selftest=Sun:16
Adding scheduled verify to slot 7 for [Sun, 4:00PM] ... Done.</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_del_rebuild_3dslot_id"><em>/cx</em> <strong>del</strong> <em>rebuild=slot_id</em></a></strong><br />
</dt>
<dd>
This command will remove (or unregister) the rebuild background task in slot <em>slot_id</em>.
</dd>
<dd>
<p>For ``rebuild'' background task description, see command <strong>/cx show rebuild</strong>.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 del rebuild=2
Removing scheduled rebuild slot [2] ... Done.</pre>
</dd>
<dd>
<p>WARNING: If all timeslots are removed, be sure to also disable the schedule.
Otherwise, no firmware initiated or manually started rebuild tasks would run.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_del_verify_3dslot_id"><em>/cx</em> <strong>del</strong> <em>verify=slot_id</em></a></strong><br />
</dt>
<dd>
This command will remove (or unregister) the verify background task in slot <em>slot_id</em>.
</dd>
<dd>
<p>For ``verify'' background task description, see command <strong>/cx show verify</strong>.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 del verify=3
Removing scheduled verify slot [3] ... Done.</pre>
</dd>
<dd>
<p>WARNING: If all timeslots are removed, be sure to also disable the schedule.
Otherwise, no firmware initiated or manually started verify tasks would run.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_del_selftest_3dslot_id"><em>/cx</em> <strong>del</strong> <em>selftest=slot_id</em></a></strong><br />
</dt>
<dd>
This command will remove (or unregister) the selftest background
task in slot <em>slot_id</em>.
</dd>
<dd>
<p>For ``selftest'' background task description, see command <strong>/cx show selftest</strong>.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
$ tw_cli /c1 del selftest=3
Removing scheduled selftest slot [3] ... Done.</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_rebuild_3d_3cenable_7cdisable_7c1_2e_2e5"><em>/cx</em> <strong>set</strong> <em>rebuild=&lt;enable|disable|1..5</em>&gt;</a></strong><br />
</dt>
<dd>
This command will <em>enable</em> or <em>disable</em> all of the scheduled rebuild background
tasks on controller <em>/cx</em>. When enabled, only registered or scheduled tasks
will execute. Any previous on-demand (manually started) background tasks will
be ignored.
</dd>
<dd>
<p>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:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>This command applies to 7000, 8000, and 9000 models controllers. For 7/8000 series,
the rebuild rate also applies to verify and mediascan tasks.</p>
</dd>
<dd>
<p>For ``rebuild'' background task description, see command <strong>/cx show rebuild</strong>.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_rebuildmode_3d_3cadaptive_7clowlatency_3"><em>/cx</em> <strong>set</strong> <em>rebuildmode=&lt;adaptive|lowlatency</em>&gt;</a></strong><br />
</dt>
<dd>
When a rebuild background task is active, if the task rate is set to high
(i.e., low I/O rate), the system latency increases and performance is negatively
affected. This command allows you to offset this condition by setting the rebuild
mode to low latency. This setting will ``throttle'' the background task and allow
host Reads to complete, thus improving performance.
</dd>
<dd>
<p>The rebuild mode has two settings: ``Adaptive'' and ``Low latency''. The Adaptive
setting tells the controller to keep its current background activity task policy
and it is the default. The Low Latency setting has been described above.</p>
</dd>
<dd>
<p>This command is associated with the rebuild task rate, please also see /cx set
rebuildrate.</p>
</dd>
<dd>
<p>This command is supported on the 9650SE controller with Release 9.5.2 or later,
and for the 9690SA and higher model controllers.</p>
</dd>
<dd>
<p><strong>Note:</strong> 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.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 set rebuildmode=lowlatency
Setting Rebuild background task mode on /c1 to [lowlatency] ... Done.</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx show rebuildmode
/cx set rebuildrate=&lt;1..5&gt;
/cx show rebuildrate</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_rebuildrate_3d_3c1_2e_2e5_3e"><em>/cx</em> <strong>set</strong> <em>rebuildrate=&lt;1..5</em>&gt;</a></strong><br />
</dt>
<dd>
The execution priority relative to I/O operations for the rebuild background task
is the rebuild task rate. The rebuild task rate set to ``fastest'' will consume all
of the controller's resources and will correspondingly deter I/O operations.
Accordingly, the converse is also true.
</dd>
<dd>
<p>This task rate is of the range [1..5], where 5 denotes the setting of fastest
background task and slowest I/O, as follows:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>This command applies to the 7000, 8000, and 9000 models controllers.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 set rebuildrate=2
Setting Rebuild background task rate on /c1 to [2] (faster I/O) ... Done.</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx show rebuildrate
/cx set rebuildmode=&lt;adaptive|lowlatency&gt;
/cx show rebuildmode</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_verify_3d_3cenable_7cdisable_7c1_2e_2e5_"><em>/cx</em> <strong>set</strong> <em>verify=&lt;enable|disable|1..5</em>&gt;</a></strong><br />
</dt>
<dd>
This command will <em>enable</em> or <em>disable</em> all of the scheduled verify background
tasks on controller <em>/cx</em>. When enabled, only registered or scheduled
tasks will execute. Any previous on-demand (manually started) background tasks
will be ignored.
</dd>
<dd>
<p>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:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>Note that this feature only applies to 9000 and higher controller models.</p>
</dd>
<dd>
<p>For ``verify'' background task description, see command <strong>/cx show verify</strong>.</p>
</dd>
<dd>
<p><strong>Note:</strong> 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.)</p>
</dd>
<dd>
<p><strong>Note:</strong> 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'.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_verify_3d_3cadvanced_7cbasic_7c1_2e_2e5_"><em>/cx</em> <strong>set</strong> <em>verify=&lt;advanced|basic|1..5</em>&gt;</a></strong><br />
</dt>
<dd>
This command only applies to controller models 9750, 9690SA and 9650SE with
Release 9.5.2 or later.
</dd>
<dd>
<p>This command is effectively the same as the 'set verify' command.
Setting verify to <em>advanced</em> enables the Verify Tasks Schedule, which
can include a series of up to 7 days and times. Setting <em>verify</em> to
<em>basic</em> creates a weekly schedule with one specific day and time, and
disables the series of scheduling slots associated with the advanced
verify task schedule.</p>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_verify_3d_3cbasic__5bpref_3dddd_3ahh_5d_"><em>/cx</em> <strong>set</strong> <em>verify=&lt;basic</em> [pref=ddd:hh]&gt;</a></strong><br />
</dt>
<dd>
This command only applies to 9650SE and higher model controllers.
</dd>
<dd>
<p>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.
</p>
</dd>
<dd>
<pre>
When you set verify=basic, the table of scheduled time slots associated with
the advanced Verify Task Schedule is ignored.</pre>
</dd>
<dd>
<p>Verify=basic is intended to be used with the auto-verify policy for RAID
units, to insure that a unit verify process occurs on a regular
basis. Also, for this reason, in systems that support Basic Verify,
auto-verify is set to ON by default.</p>
</dd>
<dd>
<p><strong>Note:</strong> 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
<em>/cx/ux start verify</em>.</p>
</dd>
<dd>
<p>For example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c3 set verify=basic pref=Fri:23
Setting /c3 basic verify preferred start time to [Fri, 11:00PM] ... Done.</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_verifymode_3d_3cadaptive_7clowlatency_3e"><em>/cx</em> <strong>set</strong> <em>verifymode=&lt;adaptive|lowlatency</em>&gt;</a></strong><br />
</dt>
<dd>
When a verify background task is active, if the task rate is set to high (i.e.,
low I/O rate), the system latency increases and performance is negatively affected.
This command allows you to offset this condition by setting the rebuild mode to low
latency. This setting will ``throttle'' the background task and allow host Reads to
complete, thus improving performance.
</dd>
<dd>
<p>The verify mode has two settings: ``Adaptive'' and ``Low latency''. The Adaptive
setting tells the controller to keep its current background activity task policy
and it is the default. The Low Latency setting has been described above.</p>
</dd>
<dd>
<p>This command is associated with the verify task rate, please also see
<em>/cx set verifyrate</em>.</p>
</dd>
<dd>
<p>This command is supported on the 9650SE controller with Release 9.5.2 or later
and for the 9690SA and higher model controllers.</p>
</dd>
<dd>
<p><strong>Note:</strong> 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.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 set verifymode=lowlatency
Setting Verify background task mode on /c1 to [lowlatency] ... Done.</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx show verifymode
/cx set verifyrate=&lt;1..5&gt;
/cx show verifyrate</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_verifyrate_3d_3c1_2e_2e5_3e"><em>/cx</em> <strong>set</strong> <em>verifyrate=&lt;1..5</em>&gt;</a></strong><br />
</dt>
<dd>
The execution priority relative to I/O operations for the verify background task
is the verify task rate. The verify task rate set to ``fastest'' will consume all
of the controller's resources to complete the task and will correspondingly deter
I/O operations. Accordingly, the converse is also true.
</dd>
<dd>
<p>This task rate is of the range [1..5], where 5 denotes the setting of fastest
background task and slowest I/O, as follows:</p>
</dd>
<dd>
<pre>
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</pre>
</dd>
<dd>
<p>This command applies to the 7000, 8000, and 9000 models controllers.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt; /c1 set verifyrate=2
Setting Verify background task rate on /c1 to [2] (faster I/O) ... Done.</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx show verifyrate
/cx set verifymode=&lt;adaptive|lowlatency&gt;
/cx show verifymode</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_selftest_3denable_7cdisable"><em>/cx</em> <strong>set</strong> <em>selftest=enable|disable</em></a></strong><br />
</dt>
<dd>
This command will <em>enable</em> or <em>disable</em> the SMART selftest task on
on the specified controller <em>/cx</em>. When enabled, the selftest task will be
performed during a scheduled timeslot.
</dd>
<dd>
<p>For ``selftest'' background task description, see command <em>/cx show selftest</em>.</p>
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt;&gt;/c2 set selftest=enable
Sending commands to enable all selftests ... Done.</pre>
</dd>
<p></p>
<dt><strong><a name="item_follow"><em>/cx</em> <strong>set</strong> <em>ondegrade=cacheoff|follow</em> (9500S only)</a></strong><br />
</dt>
<dd>
This command allows you to set a controller based write cache policy. If the policy
is set to <em>cacheoff</em>, 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 <em>follow</em>, then if a unit is degraded, firmware will
follow whatever policy has been set for that unit.
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_spinup_3dnn"><em>/cx</em> <strong>set</strong> <em>spinup=nn</em></a></strong><br />
</dt>
<dd>
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.
</dd>
<dd>
<p>Example:</p>
</dd>
<dd>
<pre>
//localhost&gt;&gt;/c2 set spinup=2
Setting Disk Spinup Policy on /c2 to [2] ... Done.</pre>
</dd>
<dd>
<p>See also:</p>
</dd>
<dd>
<pre>
/cx show spinup
/cx set stagger=nn
/cx show stagger</pre>
</dd>
<p></p>
<dt><strong><a name="item__2fcx_set_stagger_3dnn"><em>/cx</em> <strong>set</strong> <em>stagger=nn</em></a></strong