tw-cli
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
AMCC/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 9690SA
series 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 controller 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 soft-
ware 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 applicable controller series, the reference also applies to vport.
CLI supports a set of primary command syntax and a set of legacy com-
mand syntax that is the old or original command syntax. Note: The pri-
mary 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 "9KSX/SE only" 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 and 9690SA controllers.
9KSX/SE only Could be used in all controllers of the 9xxxSX or SE only.
9KSX/SE/SA only Could be used in all controllers of the 9xxxSX, SE or SA only.
The above implies an ordering of the command set hierarchy, where "No
specification" is the superset of "9000 series" that in turn is the
superset of "9KSX/SE only".
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 or
features:
Controller | Added feature / 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
----------------+-------------------------------------------
Please note that the features are accumulative down the list, excepted
where noted. Also, CCU (Chassis Control Unit) refers to JMR enclo-
sure/Sidecar.
This document, therefore, may be used as a reference for individual
commands and also as a reference for supported features. For the for-
mer 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 appropri-
ate controller (9690SA), a global view of the environment includes summary
information about detected enclosures. As example:
//localhost> show
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
CLI Compatible Range = [2.00.00.001 to 2.00.03.018]
//localhost>
show events [reverse]
show AENs [reverse]
show alarms [reverse]
This command shows the controller alarms or events, also known as AEN (Asyn-
chronous 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 sys-
tem.
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 auto-
matically to reflect this and the user would only have to type show. The con-
cept is similar to being in a particular location in a file system and
requesting a listing of the current directory.
/ 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 host-
name.
For example:
//localhost> focus //elvis.amcc.com
//elvis.amcc.com>
//elvis.amcc.com> focus /c0/u0
//elvis.amcc.com/c0/u0>
//elvis.amcc.com/c0/u0> focus ..
//elvis.amcc.com/c0>
//elvis.amcc.com/c0> focus ./u0
//elvis.amcc.com/c0/u0>
//elvis.amcc.com/c0> focus /
//elvis.amcc.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; a Unit summary listing all present
units, a Port summary section listing of all present disks and their attached
ports, and a BBU summary section listing if a BBU unit is installed on the
controller.
The Unit summary section lists all present units specifying their Unit Number,
Unit type (such RAID 5), the unit status (such as OK, VERIFYING, INITIALIZING,
etc.), the %RCompl which reports percent completion, the %V/I/M which reports
the percent completion of Verify, Initialize, or Migrating status of the unit,
the stripe size, the usable capacity in Giga (or Tera) Bytes, the write cache
setting, the read cache setting (depending support of your controller) and the
autoverify setting.
Note: If a "*" appears at the end of the status, it means one of its sub-unit
is in WARNING state which a recoverable error might be found in the corre-
sponding port.
(in which the current BBU can backup the controller write cache in the event
of power loss), temperature, voltage, and its readiness, etc.
Additional attributes about controllers, units, ports and disks can be
obtained by querying for them explicitly. See other show sub-commands below.
Typical output, for controller models of 9650SE and lower:
//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
Typical output, for the 9690SA controller:
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
While the 'Cache' column in the unit summary have been denoting the write
cache only, for controllers with read cache support (9650SE with supporting
firmware and 9690SA), the 'Cache' column displays the settings of both the
read cache and the write cache. For example:
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(9KSX/SE/SA only),
autorebuild(9KSX/SE/SA only), bios, carvesize(9KSX/SE/SA only), driver,
drivestatus, firmware, memory, model, monitor, numdrives, numports, numunits,
ctlbus(9KSX/SE/SA only), 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
//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 9690SA controller, 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 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 onde-
grade 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
/cx show autocarve (9KSX/SE/SA only)
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 carve-
size 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
This command presents the size of the memory installed on the controller.
Example:
//localhost> /c0 show memory
/c0 Available Memory = 112MB
/cx show ctlbus (9KSX/SE/SA only)
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 (9KSX/SE only)
This command shows the Auto-Rebuild policy. If the policy is enabled, the
firmware will choose following drives in order to find a candidate for rebuild
operation on a degraded unit.
1. Smallest usable capacity spare.
2. Smallest usable unconfigured drive.
3. Smallest usable capacity failed drive.
If the policy is disabled, spare drives are the only candidates for an auto-
matic rebuild operation.
Example:
//localhost> /c0 show autorebuild
/c0 Auto-Rebuild Policy = on
/cx show dpmstat [type=inst|ra|ext] (9KSX/SE/SA, except for type=ext that is
9KSE/SA only)
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 dis-
played. The options are either: inst for Instantaneous, ra for Running Aver-
age, and ext for Extended Drive Statistics. More detailed information regard-
ing 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
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 corre-
sponding port-level command with the same options, that displays correspond-
ingly 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 cur-
rently 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
/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] [nord-
cache|rdcachebasic] [autoverify] [noqpolicy] [ignoreECC] [name=string] [stor-
save=<protect|balance|perform>] [v0=n|vol=a:b:c:d] [rapidrecov-
ery=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 con-
troller, a warning is sent to standard error. 2) The default drive queuing
policy is enabled, unless it is specifically set to disable queuing by specif-
ing noqpolicy. 3) The noqpolicy attribute is not applicable to the "spare"
unit. Specifying the noqpolicy attribute returns an error.
Since this command is by far the richest command, it deserves more details.
/cx is the controller name as in /c0, /c1, etc.
type=RaidType consists of logical unit type as in raid0, raid1, raid5, raid10,
raid50, single, spare, and raid6 (9650SE and higher only).
For example:
type=raid50
The following table illustrates supported types and controller models.
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single | Raid6 |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
7K/8K | Y | Y | Y | Y | Y | Y | N | N | N |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
9K | Y | Y | Y | Y | N | Y | Y | Y | N |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
9650SE| | | | | | | | | |
and | Y | Y | Y | Y | N | Y | Y | Y | Y |
higher| | | | | | | | | |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
disk=p:-p consists of a list of ports (disks) to be used in the construction
of the specified unit type. One or more ports can be specified. Multiple ports
can be specified using ":" or "-" as port index separators. A dash indicates
a range and can be mixed with ":". For example disk=0:1:2-5:9:12 indicates
port 0, 1, 2 thru 5 (inclusive), 9 and 12.
stripe=size consists of the stripe size to be used. The following table
| 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 9690SA only.
Recall that a RAID-50 is a multi-tier array. At the most bottom layer, N num-
ber 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.
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 cre-
ated 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.
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 sup-
ported 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 |
--------+-------+-------+-------+-------+--------+------+-------+--------+--------+
9KSE/SA | N | Y | Y | Y | Y | N | N | Y | N |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
name=string attribute allows user to name the new unit. The maximum charac-
ters 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 com-
mands /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. It is a 9KSX/SE only feature. Please refer to 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. However,
if the input size exceeds the size of the array, the volume would be left
"uncarved". Note that there are two ways to set the first volume, as either
v0=n or vol=n would have the same effect.
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
//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 sys-
tem 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 9690SA and 9650SE (with support-
ing 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 vis-
its 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:
ure) is experienced, subsequent read from the disks, will inform the con-
troller 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 corre-
sponding 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 compatibil-
ity with the current controller, current driver and current application ver-
sions. Subsequently a recommendation is given to the user followed by a
prompt to continue. Once the user decides to proceed, the image will be down-
loaded 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
----------------------------------------------------------------------
/cx show events [reverse]
/cx show AENs [reverse]
/cx show alarms [reverse]
Asynchronous events or AENs (Asynchronous Event Notifications) of the con-
troller, 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 dis-
played 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 diagnostics suitable for technical support
usage. Note that some characters might not be printable or rendered correctly
(human readable). It is recommended to save this output to a file, where it
can be communicated to tech support or further studied with Linux utilities
like od(1).
Example:
$ tw_cli /c0 show diag > diag.txt
/cx show phy
This command is for the 9690SA only. It reports a list of phys with related
information for the specified controller. The 'Device Type' column indicates
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 set-
ting 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 Addesss 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 - - - 1.5-3.0 - Auto
phy5 - - - 1.5-3.0 - Auto
phy6 500050e000000006 SAS /c3/p6 1.5-3.0 3.0 Auto
phy7 - - - 1.5-3.0 - Auto
/cx show rebuild
Model 9000 series 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 illus-
trated 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
For example:
If a unit is in the initialization state at noon on Wed, the tabled schedule
above is show in the following:
$ 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
$ tw_cli /c1 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-5 INITIALIZING 0 - 64K 521.466 ON OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 NOT-PRESENT - - - -
p1 OK u0 76.33 GB 160086528 Y2NXL7FE
p2 NOT-PRESENT - - - -
p3 OK u0 76.33 GB 160086528 Y2NXLB9E
p4 NOT-PRESENT - - - -
p5 OK u0 76.33 GB 160086528 Y2NXQPZE
p6 NOT-PRESENT - - - -
p7 OK u0 76.33 GB 160086528 Y2NXM4VE
p8 OK u0 74.53 GB 156301488 3JV3WTSE
p9 OK u0 74.53 GB 156301488 3JV3WRHC
p10 OK u0 74.53 GB 156301488 3JV3WQLQ
p11 OK u0 74.53 GB 156301488 3JV3WQLZ
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK OK 0 xx-xxx-xxxx
Then if the user enables the tabled schedules, the unit initialization will be
paused until next scheduled slot comes.
$ tw_cli /c1 set rebuild=enable
Enabling scheduled rebuilds on controller /c1 ...Done.
$ tw_cli /c1 show rebuild
Rebuild Schedule for Controller /c1
========================================================
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-5 INIT-PAUSED 0 - 64K 521.466 ON OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 NOT-PRESENT - - - -
p1 OK u0 76.33 GB 160086528 Y2NXL7FE
p2 NOT-PRESENT - - - -
p3 OK u0 76.33 GB 160086528 Y2NXLB9E
p4 NOT-PRESENT - - - -
p5 OK u0 76.33 GB 160086528 Y2NXQPZE
p6 NOT-PRESENT - - - -
p7 OK u0 76.33 GB 160086528 Y2NXM4VE
p8 OK u0 74.53 GB 156301488 3JV3WTSE
p9 OK u0 74.53 GB 156301488 3JV3WRHC
p10 OK u0 74.53 GB 156301488 3JV3WQLQ
p11 OK u0 74.53 GB 156301488 3JV3WQLZ
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK OK 0 xx-xxx-xxxx
/cx show rebuildmode
This command shows the current rebuild mode setting of the specified con-
troller. 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 "throt-
tles" the background task and allow host Reads to complete, thus improves per-
formance 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 supporting firmware
installed (version FE9X 4.07.00.002 or higher) and for the 9690SA and higher
model controllers.
For 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
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 show verify shows you the
current verify schedule.
For 9650SE and 9690SA RAID controllers, the Verify Task Schedule can be either
basic or advanced (For details about the two types and the associated com-
mands, 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 auto-verification of units. The advanced Verify Task Schedule pro-
vides 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 a task. The task
schedule has a slot id, start-day-time, duration, and status attributes.
Rebuilds, migrations, and initializations 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. Veri-
fying 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 9550SX and earlier controllers, and when verify=advanced for
9650SE and 9690SA 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
/c1 basic verify weekly preferred start: Friday 12:00am
/cx show verifymode
This command shows the current verify mode setting of the specified con-
troller. 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 "throt-
tles" the background task and allow host Reads to complete, thus improves per-
formance 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 supporting firmware
installed (version FE9X 4.07.00.002 or higher) and for the 9690SA and higher
model controllers.
For 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>
are checked once each day by default.
UDMA self test entails checking the current parallel ATA bus speed (between
controller and attached disk), which could have been throttled down during
previous operations, and increases the speed for best performance (usually one
level higher). Possible speeds include 33, 66, 100 and 133 Mhz. Note that the
UDMA selftest is not applicable (or required) with SATA drives, but is left
enabled by default.
SMART selftest instructs the controller to check certain SMART supported
thresholds by the disk vendor. An AEN is logged to the alarms page 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 illus-
trated below.
$ tw_cli /c1 show selftest
Selftest Schedule for Controller /c1
========================================================
Slot Day Hour UDMA SMART
--------------------------------------------------------
1 Sun 12:00am enabled enabled
2 Mon 12:00am enabled enabled
3 Tue 12:00am enabled enabled
4 Wed 12:00am enabled enabled
5 Thu 12:00am enabled enabled
6 Fri 12:00am enabled enabled
7 Sat 12:00am enabled enabled
/cx add rebuild=ddd:hh:duration
This command adds a new background rebuild task to be executed on the day ddd
(where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at the hour hh (range 0
.. 23), for a duration of duration (range 1 .. 24) hours. This command will
fail if no (empty) slot is available.
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.
Will add a rebuild background task schedule to be executed on Sundays at 4:00
PM for a duration of 3 hours.
/cx add verify=ddd:hh:duration
This command adds a new task slot to the Verify Task Schedule on the day ddd
(where ddd is Sun, Mon, Tue, Wed, Fri, or Sat), at hour 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.
For 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 exe-
cuted 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 adds a new background selftest task to be executed on day ddd
(where ddd is Sun, Mon, Tue, Wed, Thu, Fri, and Sat), at hour <hh> (range 0 ..
23). Notice that selftest runs to completion and as such no duration is pro-
vided. This command will fail if no (empty) slot is available.
For "selftest" background task description, see command /cx show selftest.
For example:
//localhost> /c1 add selftest=Sun:16
Adding scheduled verify to slot 7 for [Sun, 4:00PM] ... Done.
Will add a selftest background task schedule to be executed on Sundays at 4:00
PM.
/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.
For example:
$ tw_cli /c1 del rebuild=2
Will remove rebuild background task in slot 2.
WARNING: If all timeslots are removed, be sure to also disable the schedule.
Otherwise the applicable background task will never occur.
/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.
For example:
$ tw_cli /c1 del verify=3
Will remove rebuild background task in slot 3.
Will remove selftest background task in slot 3.
WARNING: If all timeslots are removed, be sure to also disable the schedule.
Otherwise the applicable background task will never occur.
/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 tabled or, registered/scheduled
tasks will execute. Any previous on-demand 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 con-
sume 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 nega-
tively 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 pol-
icy 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 supporting firmware
installed (version FE9X 4.07.00.002 or higher) and for the 9690SA and higher
model controllers.
Note: Setting rebuildmode to 'low latency' and rebuildrate to '1' is not rec-
ommended 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.
For example:
//localhost> /c1 set rebuildmode=lowlatency
Setting Rebuild background task mode on /c1 to [lowlatency] ... Done.
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 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 tabled or , registered/scheduled
tasks will execute. Any previous on-demand 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
9690SA 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 verification to occur automatically, when enabling the ver-
ify schedule you must also remember to enable the autoverify setting for the
units to be verified. For more information, see the command '/cx/ux set
autoverify'.
This command only applies to 9650SE and the 9690SA RAID 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 you can omit the day and time and use the
default of Friday midnight/Saturday morning.
When you set verify=basic, the series of scheduled days and times 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 verification of the unit 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 immedi-
ately. 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 nega-
tively 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 pol-
icy 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 supporting firmware
installed (version FE9X 4.07.00.002 or higher) and for the 9690SA and higher
model controllers.
Note: Setting verifymode to 'low latency' and verifyrate to '1' is not recom-
mended 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.
For example:
//localhost> /c1 set verifymode=lowlatency
Setting Verify background task mode on /c1 to [lowlatency] ... Done.
See also:
/cx show verifymode
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 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 [task=UDMA|SMART]
This command will enable or disable all or a particular task=selftest_task
(UDMA or SMART) on a specified controller /cx. When enabled, only specified
task=selftest_task task will be performed during a scheduled timeslot. If no
task is specified, the command is applicable to both tasks.
For "selftest" background task description, see command /cx show selftest.
For example:
$ tw_cli /c0 selftest=enable task=UDMA
Will enable UDMA selftest on controller c0.
/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 to the number of disks/ports sup-
ported 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, etc,
etc. The amount of time to pause can be specified with the spin up stagger
time policy.
/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 to 60 seconds. This
policy in conjunction with disk spin up policy specifies how the controller
tistics, 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.
For 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 (9KSX/SE/SA only)
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 lim-
ited 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.
/cx set carvesize=[1024..32768] (9KSX/SE/SA only)
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.
/cx set autorebuild=on|off (9KSX/SE/SA only)
This command sets Auto-Rebuild policy to be on or off. If the policy is on,
the firmware will choose drives in the following priority order for a candi-
date of a rebuild operation (on a degraded unit).
1. Smallest usable capacity spare.
2. Smallest usable unconfigured drive.
3. Smallest usable capacity failed drive.
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.
autodetect=on|off attribute configures the controller drive auto-detect set-
ting. 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.
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 speci-
fied. 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
This command applies to 7000/8000 controllers. It provides media scrubbing for
validating functionality of a disk. This includes bad block detection and
remapping, etc. The commands starts a media scan operation on the specified
controller /cx.
/cx stop mediascan
This command applies to 7000/8000 controllers. It provides media scrubbing for
validating functionality of a disk. This includes bad block detection and
remapping, etc. The commands stops a media scan operation on the specified
controller /cx.
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/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 shows the precentage completion of the processes associ-
ated with the unit with %RCompl (percent Rebuild completion) and %V/I/M (per-
cent 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 of the process is for the current
active process, and (P) denotes that the percentage completion of the process
is for the current paused process. For example:
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 sta-
tus and percentage show the composite unit status and composite rebuild per-
centage.
/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), qpol-
icy(9KSX/SE/SA Only), rebuildstatus, serial(9000 series), status, stor-
save(9KSX/SE/SA Only), 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 9KSX/SE/SA controllers; the attribute rapidrecovery is only
applicable to 9KSE/SA controllers; the attribute parity is only applicable to
the RAID-6 array; and the rdcache attribute is applicable for the 9650SE and
newer controllers with release 9.5.2 or later.
/cx/ux show status
This command presents the status of the specified unit.
Example:
//localhost> /c0/u0 show status
/c0/u5 status = OK
/cx/ux show rebuildstatus
This command presents the rebuildstatus (if any) of the specified unit.
Example:
/cx/ux show initializestatus
This command presents 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 presents the number of volumes of the specified unit.
Example:
//localhost> /c0/u5 show volumes
/c0/u5 Volume(s) = 2
/cx/ux show name (9000 series)
This command presents 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 presents the unique serial number of the specified unit.
Example:
//localhost> /c0/u5 show serial
/c0/u5 Serial Number = 12345678901234567890
/cx/ux show qpolicy (9KSX/SE/SA only)
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 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 (9KSX/SE/SA only)
This command presents the storsave policy (protect|balance|perform) of the
firmware on the unit.
For detail, see /cx/ux set storsave=protect|balance|perform (9KSX/SE only).
Example:
/cx/ux show autoverify (9000 series)
This command presents 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 9650SE and newer controllers with release 9.5.2
or later. This feature is supported in all arrays types.
Example:
//localhost> /c0/u0 show rdcache
/c0/u0 Read Cache = Intelligent
/cx/ux show ignoreECC (9000 series)
This command presents 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 (9KSE/SA only)
This command only applies to the 9650SE and 9690SA controllers, and for redun-
dant arrays. Also, Firmware 9.5.1 or later is required.
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>.
For example:
//localhost> /c0/u0 show rapidrecovery
/c1/u0 Rapid RAID Recovery policy setting = disable
/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 recov-
ered. 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 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 |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
9KSE/SA | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
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 func-
tionality 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 simi-
lar 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 |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
/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. Oth-
erwise, 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 dis-
able the autoverify operation on the specified unit. This feature only
applies to 9000 models.
For a newly created unit on 9650SE and 9690SA controllers running 9.5.1 or
later, 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 |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
9KSE/SA | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
--------+-------+-------+-------+-------+--------+--------+--------+------+-------+
/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 per-
formance 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
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 9650SE and newer controllers with release 9.5.2
or later. This feature is supported in 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 (9KSX/SE/SA only)
This command allows you to identify a unit within an enclosure. The LEDs of
the drive slots that are associated with the specified unit would blink.
For example:
//localhost> /c0/u0 set identify=on
Sending Identify request for unit /c0/u0 to [on] ... Done.
/cx/ux set ignoreECC=on|off
junction 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 (9KSX/SE/SA only)
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 unit, 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 (9KSE/SA only)
/cx/ux set rapidrecovery=disable [quiet]
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 applica-
ble 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] (9KSX/SE/SA only)
This command sets the storsave policy of the firmware to be either protect,
balance, or perform when the unit write cache is enabled.
This feature is available only within 9KSX/SE/SA controller family or above.
There is a tradeoff among the available settings. The following description
about the settings should help you to decide which one is suitable to you and
your application. The protect mode is the default setting.
controller settings. When user sets the storsave to perform mode, 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.
When storsave is set to perform, a warning about the data loss in the event of
power failure is giving to user to confirm the option. If user want to skip
the confirmation, [quiet] option can be used to by pass the warning.
balance -- provide more data protection than perform mode but less data pro-
tection than protect mode. And provide better performance than protect mode
but less performance than perform mode. When user sets the storsave to the
balance mode, 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 sim-
ilar rules and policies that apply when creating a new unit. For example, a
valid number of disks and parameters must be specified. The destination unit
must use all source disks and potentially augment the number of disks in the
disk=p:-p disk list. Unspecified parameters are assigned default values
(stripe size of 64K, write cache enabled, autoverify disabled, and ignoreECC
disabled).
The unit to be migrated (source unit) must be in a normal state (not degraded,
initializing, or rebuilding) before the migration. If the source unit is of
type RAID-1 and the destination unit is of type single, the disk-specifier of
the migration command [disk=p:-p] is actually not optional and must not be
included in the command. The drives in the RAID-1 array would become multiple
units of type single after the migration, and the source drives are the desti-
nation drives. Specifying more drives with the "disk=" option would return an
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.
ble 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) of 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 fragmenta-
tion and a moving target.
nocache instructs CLI to disable the write cache on the migrated unit.
Enabling write cache increases performance, but at the cost of potential data
loss in the event of sudden power loss (unless a BBU or UPS is installed). By
default the cache is enabled. Unless there is a BBU or UPS installed, to
avoid the possibility of data loss in the event of sudden power loss, it is
recommended that nocache be specified.
autoverify enables the autoverify attribute on the unit to be migrated. For
more details on this feature, refer to "cx/ux set autoverify" section of this
document.
Migration Process. In all cases of migration, the background migration
process must be completed before the newly sized unit is available for use.
You can continue using the original unit during this time. Once the migration
is finished, a reboot will be required if you are booted from the unit. For
secondary storage, depending on your operating system, you may need to first
unmount the unit, then use CLI to 'remove' and 'rescan' the unit so that the
operating system can see the new capacity, and then remount the unit.
You may also need to resize the file system or add a new partition. For
instructions, consult the documentation for your operating system.
Note: It is important that you allow migration to complete before adding
drives to the unit or move it to another controller. Making any physical
changes to the unit during migration may cause the migration to stop, and can
jeopardize the safety of your data.
Examples. The two examples which follow show the usage of this command for
splitting a mirror and for capacity expansion, respectively. Following those
are sample outputs of the migrate function. After which example outputs show-
ing the special case are presented.
Example of split mirror:
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
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 Status Unit Size Blocks Serial
---------------------------------------------------------------
p5 OK u5 149.05 GB 312581808 WD-WMACK1406498
The above report indicate that port 5 of controller 0 is attached to one West-
ern Digital disk with status OK participating in unit 5.
For the 9690SA, 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, the drive type, controller phy number, the 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 com-
mand, or the "show all" command.) Please also note that the port handle as a
virtual port is indicated by the heading or column "VPort".
/cx/px show Attribute Attribute ...
This command shows the current setting of the given attribute(s) on the speci-
fied 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
---------------+---------------------------------------------
9KSX/SE/SA | ncq, identify, lspeed
---------------+---------------------------------------------
9KSE/SA | rasect, pohrs, temperature, spindlespd
---------------+---------------------------------------------
9690SA only | driveinfo, ports, connections, drvintf, wwn
---------------+---------------------------------------------
/cx/px show status
This command presents the status of 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 speci-
fied 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 only status of the drive, and
does not contain other information such as unit, type, size, etc.
//localhost> /c0/p5 show serial
/c0/p5 Serial = WD-WMACK1406498
/cx/px show firmware
This command presents the firmware version of the specified port.
Example:
//localhost> /c0/p5 show firmware
/c0/p5 Firmware Version = 65.13G65
/cx/px show identify (9KSX/SE/SA only)
This command presents the LED status of the port for specified port.
Example:
//localhost> /c0/p5 show identify
/c0/p5 Identify Status = on
/cx/px show ncq (9KSX/SE/SA only)
This command presents the NCQ (Native Command Queueing) information of the
port.
Example (for 9KSX/SE):
//localhost> /c0/p5 show ncq
/c0/p5 NCQ Supported = No
/c0/p5 NCQ Enabled = No
Example (for 9KSX/SE):
//localhost> /c3/p0 show ncq
/c3/p0 Queuing Supported = Yes
/c3/p0 Queuing Enabled = Yes
/cx/px show lspeed (9KSX/SE/SA only)
This command presents the SATA link speed supported by the disk behind the
port and the actual speed 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 presents the capacity, both in human readable (such as GB) and
block count of the specified port. Note that at this writing, human readable
format is computed based on division by 1000 (not 1024) as is popular with
I/O bandwidth.
Note that for the 9690SA controller, SMART data is not applicable and as such
this command is not supported for the 9690SA.
Example:
//localhost> /c0/p5 show smart
10 00 01 0B 00 C8 C8 00 00 00 00 00 00 00 03 07
00 9A 96 BC 14 00 00 00 00 00 04 32 00 64 64 7A
00 00 00 00 00 00 05 33 00 C8 C8 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C
Note that at this writing, we are not decoding the SMART data. Also note that
if the disk attached to the specified port is not present or there are cabling
problems reaching the disk, CLI will return an error. This could be one way of
detecting whether a disk is present or not.
/cx/px show driveinfo (9690SA only)
This command shows the drive related inforamtion of the specified drive.
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|ext (9KSX/SE/SA, except for
type=ext that is 9KSE/SA only)
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 sec-
tion 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
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 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 form
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
rescan. 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. 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, 9590SE and 9690SA only)
This command sets the LED status of the port. If the identify is set to on,
the firmware activates the setting of the corresponding LED of the port. If
the setting of the configuration for LED is blinking for identify=on, this
will blink the LED of the port.
Note: Enclosure services hardware is also required.
Example:
//localhost> /c0/p5 set identify=on
Setting Port Identify on /c0/p5 to [on] ... Done.
/cx/px set dpmstat=clear [type=ra|lct|ext] (9KSX/SE/SA except for type=ext
that is 9KSE/SA only)
This command clears the statistics counters of the Drive Performance Monitor.
The optional 'type' in the command specifies which statistics 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 speci-
fied, the default is the same as type=ra.
Here is an example of clearing the Running Average and Histdata statistics:
---------------------------------------------------------------------
p3 OK u0 0 0 0.000 0
Similarly the display for Histogram data would also be all zeros.
For examples of other statistic data types, please see 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 (9690SA 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 capa-
bility 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 (9690SA only)
This command sets the link speed of the phy. The possible values are, for
SATA: auto, 1.5, and 3.0. And for SAS: auto and 3.0. The units are in Giga-
bits per second (Gbps). The default is auto.
//localhost> /c0/phy0 set link=1.5
Setting Link Speed Control on /c0/phy0 to [1.5 Gbps] ... Done.
BBU Object Messages
BBU (Battery Backup Unit) Object Messages are commands (a.k.a. methods/mes-
sages) that are sent to an instance of a BBU such as /c0/bbu. This object is
only available on 9000 series controllers where the BBU is actually installed.
/cx/bbu show
This command presents a summary report on the specified BBU object.
For example:
//localhost> /cx/bbu show
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
nate the loop. Possible attributes are: batinst, bootloader, cap, fw,
lasttest, pcb, ready, serial, status, temp, 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 com-
plete. 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 automati-
cally by the BBU whenever necessary. During the charging, the BBU is not
capable of backup operation and the write cache is disabled. Once charg-
ing 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 back-
ing 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.
This command shows 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
This command shows 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 cap
This command shows the battery capacity in hours.
/cx/bbu show serial
This command shows the BBU serial number.
/cx/bbu show fw
This command shows the BBU board firmware version number.
/cx/bbu show pcb
This command shows the PCB revision number on the BBU unit.
/cx/bbu show bootloader
This command shows the BBU's Boot Loader version.
/cx/bbu show all
This command shows the current settings of all above attributes on the BBU
board.
For 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
//localhost>
/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 opera-
tion and the write cache is disabled. The performance of all the 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.
/cx/bbu disable [quiet]
This command disables the BBU detection on the controller. In this situation,
the controller ignores the existence of the BBU when the BBU detection is dis-
abled. In another words, when a BBU attaches to a controller and the BBU
detection is disabled, the storage management software will show user that
there is no BBU installed on this controller. This is because the BBU detec-
tion is disabled. 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 mes-
sages 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, tempera-
ture sensor, and power supply elements.
The command descriptions and examples of this section are shown with the syn-
tax 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, configu-
rations, and enclosure elements.
--------------------------+------------------------------------------
Controller -> | 9650SE | 9690SA
--------------------------+------------------------------------------
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
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: controllers, slots, fans, temp and pwrs.
/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.
/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 temper-
ature 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 set-
ting of the power supplies.
Example:
IDs, the Status column lists the status of each alarm, the State column indi-
cates 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.
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 speci-
fied 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 sup-
ports Slot Identify. If supported, setting it to ON will blink the LED of the
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 enclo-
sure 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 enclo-
sure unit.
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 Iden-
tify, 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 pos-
sible 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 sup-
ply. 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/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 possi-
ble status values are OK, FAIL, NOT-INSTALLED, and ACTIVATED. The status val-
ues 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 pro-
vides 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 set-
ting 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
tent 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 pro-
vides command syntax information, while detail about the command is
deferred to the manpage. Just as the command set have implicit level-
ing 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 pro-
vides, these includes the shell object, and controller and enclosure
objects:
//localhost> help
Copyright (c) 2008 AMCC
AMCC/3ware CLI (version 2.00.08.007)
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/bbu BBU specific commands. (9000 only)
/cx/ex Enclosure specific commands. (9690SA only)
/ex Enclosure specific commands. (9KSX/SE only)
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 out-
put.
As indicated, help<command> would give more information about the com-
mand or, display all possible sub-commands associated with the speci-
fied object. For example, for Help on the controller object /cx:
//localhost> help /cx
/cx show
/cx show selftest (9000 series)
/cx show phy (9690SA only)
/cx show dpmstat [type=<inst|ra|ext>]
(9KSX/SE/SA for type=inst and type=ra; 9KSE/SA for type=ext)
/cx add type=<RaidType> disk=<p:-p..> [stripe=<Stripe>] [noscan] [nocache]
[group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>] (group=13-16 9690SA only)
[name=string (9000 series)] [ignoreECC] [autoverify] [noqpolicy]
[v0=n|vol=a:b:c:d] (n,a,b,c,d = size of volume in GB) (9000 series)
[storsave=<protect|balance|perform>] (9KSX/SE/SA)
[rapidrecovery=<all|rebuild|disable>] (9KSE/SA only)
RaidType = { raid0, raid1, raid5, raid10, raid50, single,
spare, raid6 (9650SE and 9690SA) }
/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 (9KSX/SE/SA)
/cx set carvesize=[1024..32768] (9KSX/SE/SA)
/cx set rebuild=enable|disable|<1..5> (enable|disable for 9000 series)
/cx set verify=enable|disable|<1..5> (enable|disable for 9000 series)
/cx set verify=advanced|basic|<1..5> (9KSE/SA only)
/cx set selftest=enable|disable [task=UDMA|SMART] (9000 series)
/cx set autorebuild=on|off (9KSX/SE/SA)
/cx set autodetect=on|off disk=<p:-p>|all (9000 series)
/cx set dpmstat=on|off (9KSX/SE/SA)
/cx set verify=basic [pref=ddd:hh] where hh= {01..23} and
ddd = {mon|tue|wed|thu|fri|sat|sun} (9KSE/SX only)
/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.
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..> [stripe=<Stripe>] [noscan] [nocache]
[group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>] (group=13-16 9690SA only)
[name=string (9000 series)] [ignoreECC] [autoverify] [noqpolicy]
[v0=n|vol=a:b:c:d] (n,a,b,c,d = size of volume in GB) (9000 series)
[storsave=<protect|balance|perform>] (9KSX/SE/SA)
[rapidrecovery=<all|rebuild|disable>] (9KSE/SA only)
An alternate way to use Help is with '?' or 'help' at the end of a com-
mand string. That is, starting with the object, followed by the com-
mand, followed by '?' or 'help'. For example, '/c0' being our object
and 'show' is our command:
//localhost> /c0 show ?
/cx show
/cx show [pause [lines=n]]
/cx show Attribute [Attribute ...] where Attribute is:
achip|allunitstatus|autocarve(9KSX/SE/SA)|bios|driver|firmware
autorebuild(9KSX/SE only)|carvesize(9KSX/SE/SA)
drivestatus[pause[lines=n]]|ctlbus(9KSX/SE/SA)
memory|model|monitor|numdrives|numports|numunits|unitstatus
ondegrade(9500S only)|pcb|pchip|serial|spinup|stagger
/cx show all where all means Attributes and configurations.
/cx show diag
/cx show alarms [reverse]
/cx show rebuild (9000 series)
/cx show verify (9000 series)
/cx show selftest (9000 series)
/cx show phy (9690SA only)
/cx show dpmstat [type=<inst|ra|ext>]
(9KSX/SE/SA for type=inst and type=ra; 9KSE/SA for type=ext)
Note: Again, Help stops at the command keyword level, so that '/c0 show
selftest help' or '/c0 show phy ?' would respond with an output identi-
cal to /c0 show ?. In this case no error follows. Please also note
that if /c0 is not a valid controller is your system, an error is gen-
erated 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 is a list of the Help Commands. A brief description fol-
lows each command.
help
This command provide a table of contents, providing an overall navigational
help. Typical output looks like:
//localhost> help
Copyright(c) 2004-2006 Applied Micro Circuits Corporation(AMCC). All rights reserved.
AMCC/3ware CLI (version 2.00.07.003b)
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.
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 vari-
ous 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 Ser-
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, illus-
trating various ways to use the /cx/ex/pwrsx command. See the "Enclosure Ele-
ment 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 func-
tion 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 sys-
tem.
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
Features
This section lists some of the features that CLI supports for the 3ware
RAID product. As mentioned previously, while some of the system fea-
tures require using only a few commands, other features may require or
involve a set of commands that work together. Also, some of these fea-
ture may be compenhensively more complex to described as a few com-
mands. The purpose of this section is to provide an encapsulated view
of these features.
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 appli-
cable, and related information such as setup and operation details of a
feature and its function. The following is a list of the features in
this section:
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 Com-
mand 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 should be consistent across the two sections.
Drive Performance Monitor
Performance monitoring and statistics of the RAID controller, as a basis
for analysis of performance, may also provide information for qualifica-
tion and diagnostics. The Drive Performance Monitor of CLI supports sta-
tistics 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 execu-
tion 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
supported on the 9650SE and 9690SA 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 com-
mands 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 Perfor-
mance 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 exam-
ples 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.
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 spec-
ified 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 num-
ber of commands with high latency that are saved. The number of elements
in the buffer is determined by these configurations and the memory con-
straints of the system.
To set the Drive Performance Monitor to 'enable' or 'disable', use com-
mands /cx set dpmstat=on and /cx set dpmstat=off, respectively. For exam-
ple:
//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
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 dis-
played.
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
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
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
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 pro-
cesses and tasks in response to an unclean system shutdown. Effectively
this feature provides for expedited boot-up time.
This feature is supported on the 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 fea-
ture 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 sum-
mary 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 can-
not 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
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:
ume may be considered, although not necessarily, the Boot LUN. This fea-
ture allows the user to specify up to four volumes or LUNs in a unit.
You can define the LUN sizes for these array types: Raid0, Raid1, Raid10,
Raid5, Raid50, Raid6 and Single.
To specify Variable LUN Carve simply requires setting an attribute during
unit creation. However, to eliminate potential confusion with the exist-
ing 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
(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" com-
mand 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
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 times-
lots 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 deci-
sion 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
/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
| | | be paused).
-------------+----------------------+------------------------+------------------------
/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 Ver-
ify 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
//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 | | |
-------------+----------------------+------------------------+------------------------
Please note that this is the lower part of the table in the previous sec-
tion 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 ver-
ify 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 speci-
fied, 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 9650SE and 9690SA
controllers only. 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, we tell the RAID sys-
tem that we are selecting Basic Verify along with the preferred day and
time of the background verify task:
//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 controller's weekly
verify task that was previously set:
//localhost>> /c0 show verify
/c0 basic verify weekly preferred start: Friday, 11:00PM
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 informa-
tion 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 eas-
ily 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 set-
ting 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 offi-
cial AMCC/3ware representatives.
Initialization Process Control
This document was written by previous developers of the Command Line
Interface (CLI) software. Thereafter it has been augmented with
respect to new commands and features, including the newly added 'Fea-
ture' section, and with updates and modifications when necessary or
possible, by Marian M. Choy.
SEE ALSO
AMCC/3ware CLI User Guide
AMCC/3ware User Guide
AMCC/3ware Installation Guide
http://www.amcc.com
Version 2009-03-26 TW_CLI(8)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2013
Hurricane Electric.
All Rights Reserved.