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