On Apache
Under GNU General Public License
2012-05-26 04:16 @38.107.179.238 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
TW_CLI(8) AMCC/3ware Storage Management CLI TW_CLI(8)
NAME
tw_cli(8) - AMCC/3ware Storage Controller Management Command Line Interface.
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 Program-
ming 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 exam-
ples 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 "con-
troller 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 software to uniquely identify a drive. The port ID or vport ID allows a drive to
be consistently identified, used and managed in a RAID unit. For dual-ported drives,
although there are two connections to a drive, the drive is still identified with one
vport handle. Note: With the controller summay via the command "show", the number of
(V)Ports shown may contain two times (2X) the number of drives (suggesting the dual-ported
drive type) even though the (V)Port column of the summary to the command "/cx show" con-
tains only the number of vports corresponding to the number of drives. This is because
the drive is identified with only one vport handle.
NOTE: For all practical purposes, hereafter port and vport are used interchangeably in
reference to a drive (or disk). Therefore, unless otherwise specified, the mention of
port implies vport as well. That is, while "port" is mentioned to denote a drive, it is
implied that for the applicable controller series, the reference also applies to vport.
CLI supports a set of primary command syntax and a set of legacy command syntax that is
the old or original command syntax. Note: The primary command syntax replaces that legacy
command syntax and as such support for legacy commands will discontinue in the near
future.
Please also note that some of the commands listed in this document are qualified with
restrictions of controller type/model support. For example, "9000 series" or "9KSX/SE
only" may be next to a command. The following is a summary of the qualifications.
Commands with:
No qualifications 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/SX 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 qualification" is
the superset of "9000 series" that in turn is the superset of "9KSX/SE only".
For the Mac OS-X system, while still true, the command qualifications 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.
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 ker-
nel device drivers should be loaded for the list to show all controllers. The intention is to
provide a global view of the environment.
Typical output looks like:
//localhost> show
Ctl Model Ports Drives Units NotOpt RRate VRate BBU
--------------------------------------------------------------------------------
c0 7500-12 12 8 3 1 2 - -
c1 9506S-12 12 6 1 0 3 5 TESTING
The output indicates that Controller 0 is a 7500 model with 12 Ports, with 8 Drives detected
(attached), total of 3 Units, with one unit in a NotOpt (Not Optimal) state, a RRate(Rebuild
Rate) of 2, VRate(Verify Rate) of '-' (Not Applicable), BBU of '-' (Not Applicable). Not Optimal
refers to any state except OK and VERIFYING. Other states include INITIALIZING, INIT-PAUSED,
REBUILDING, REBUILD-PAUSED, DEGRADED, MIGRATING, MIGRATE-PAUSED, RECOVERY, INOPERABLE, and
UNKNOWN.
For a system with an enclosure unit as an attached expander, and the appropriate controller
(9690SA), a global view of the environment includes summary information about detected enclo-
sures. As example:
//localhost> show
Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU
---------------------------------------------------------------------------
c0 G133e/Astor 12 4 1 0 1 1 -
Encl Slots Drives Fans TSUnits PSUnits
--------------------------------------------------
/c0/e0 4 2 1 1 1
The enclosure summary information shows the name of the enclosure, and the number of elements
within each element type that is part of the system as identified during discovery.
show ver
This command will show the CLI and API version.
For example:
//localhost> show ver
CLI Version = 2.00.03.018
API Version = 2.01.00.004
CLI Compatible Range = [2.00.00.001 to 2.00.03.018]
//localhost>
show alarms [reverse]
This command shows the alarms or AEN messages of all controllers in the system. The default is
to display the most recent message first. The reverse attribute offers the display order to be
the most recent message last.
show diag
This command shows the diagnostic information of all controllers in the system.
show rebuild
This command displays all rebuild schedules of all the 9000 controllers in the system.
show verify
This command displays all verify 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.
update fw=filename_with_path [force]
This command iterates through all the controllers in the system and downloads the specified
firmware image to the architecturally compatible controllers. Please refer to command /cx update
fw=filename_with_path [force] for detail.
focus Object
This command will set the specified object in focus. This command is active in interactive mode
only and is provided to reduce typing. Recall that messages (or commands) are sent to objects
such as
//hostname/c0/u0 show
Instead, if the focus is set to //hostname/c0/u0, the prompt is changed automatically to reflect
this and the user would only have to type show. The concept is similar to being in a particular
location in a file system and requesting a listing of the current directory.
object can have the following forms:
//hostname/cx/ux specifies the fully qualified URI of an object on host hostname, controller cx,
unit ux.
//hostname specifies root of host hostname. The hostname is the name of the system where your
3ware RAID controllers are. With current releases, the hostname here should be always your sys-
tem's name.
.. specifies one level up (the parent object).
/ specifies the root at the current focused host.
./obj specifies the next level of the object.
/c0/bbu specifies a relative path with respect to the current focused hostname.
For example:
//localhost> focus //elvis.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 follow-
ing 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 state setting, 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 corresponding port.
For controller models up to the 9650SA series, the Port summary section lists all present ports
specifying the port number, disk status, unit affiliation, size (in human readable and blocks of
512 bytes), and disk vendor assigned serial number.
For the 9690SA controller series, this section lists virtual ports specifying the VPort number,
disk status, unit afflication, drive type, phy number (if direct attached), the enclosure and
slot (if expander attached), and model number of the drive.
The BBU summary section lists a few important attributes such as hours left (in which the current
BBU can backup the controller 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
/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, carve-
size(9KSX/SE/SA only), driver, drivestatus, firmware, memory, model, monitor, numdrives,
numports, numunits, ctlbus(9KSX/SE/SA only), ondegrade(9000S only), pcb, pchip, serial, spinup,
stagger, and unitstatus.
/cx show driver
This command reports the device driver version associated with controller /cx.
Example:
//localhost> /c0 show driver
/c0 Driver Version = 1.02.00.036
/cx show model
This command reports the controller model of controller /cx.
Example:
//localhost> /c0 show model
/c0 Model = 7500-12
/cx show firmware
This command reports the firmware version of controller /cx.
Example:
//localhost> /c0 show firmware
/c0 Firmware Version = FE9X 3.03.06.X03
/cx show bios
This command reports the BIOS version of controller /cx.
Example:
//localhost> /c0 show bios
/c0 BIOS Version = BG9X 2.01.00.026
/cx show monitor
This command reports the monitor (firmware boot-loader) version of controller /cx.
Example:
//localhost> /c0 show monitor
/c0 Monitor Version = BLDR 1.00.00.008
/cx show serial
This command reports the serial number of the specified controller /cx.
Example:
//localhost> /c0 show serial
/c0 Serial Number = F12705A3240009
/cx show pcb
This command reports the PCB (Printed Circuit Board) revision of the specified controller /cx.
Example:
//localhost> /c0 show pcb
/c0 PCB Version = Rev3
/cx show pchip
This command reports the PCHIP (PCI Interface Chip) version of the specified controller /cx.
Example:
//localhost> /c0 show pchip
/c0 PCHIP Version = 1.30-33
/cx show achip
This command reports the ACHIP (ATA Interface Chip) version of the specified controller /cx.
Example:
//localhost> /c0 show achip
/c0 ACHIP Version = 3.20
/cx show numports
For controller models other 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 capacity of the specified con-
troller /cx. Connections consists of vports and phys.
Example:
//localhost> /c3 show numports
/c3 Connections = 4 of 128
/cx show numunits
This command reports the number of units currently managed by the specified controller /cx. This
report does not include off-line units (or removed units).
Example:
//localhost> /c0 show numunits
/c0 Number of Units = 1
/cx show numdrives
This command reports the number of drives currently managed by the specified controller /cx.
This report does not include (logically) removed/exported drives. Also note that physically
removed disk(s) will not be detected unless I/O is performed against the disk. See /cx/px show
smart for a workaround.
Example:
//localhost> /c0 show numdrives
/c0 Number of Drives = 5
/cx show spinup (9000 series)
This command presents the number of concurrent disks spin up at the power on.
Example:
//localhost> /c0 show spinup
/c0 Disk Spinup Policy = 1
/cx show ondegrade (9000S only)
This command presents the cache policy for degraded units. If the ondegrade policy is Follow
Unit Policy, a unit 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 carvesize is 2 TB.
This feature is useful for operating systems limited to 2 TB filesystems. For 64-bit OS users,
there is no need to set the policy to be "on" unless users want to have multiple smaller volumes
to the OS. For 32-bit OS users, it is recommended to keep the policy on unless users know their
OS supports more than 2 TB disk devices.
When autocarve policy is off, all the new unit creation consists of one single volume.
Example:
//localhost> /c0 show autocarve
/c0 Auto-Carving Policy = on
/cx show carvesize (9KSX/SE/SA only)
This command shows the carvesize that Auto-Carving policy needs. The carve size is between 1024
to 2048 GB. Default carvesize is 2048 GB (i.e. 2 TB). See "/cx show autocarve" command above
for details.
Example:
//localhost> /c0 show carvesize
/c0 Auto-Carving Size = 2000 GB
/cx show memory
This command presents the size of the memory installed on the controller.
Example:
//localhost> /c0 show memory
/c0 Available Memory = 112MB
/cx show ctlbus (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 automatic rebuild opera-
tion.
Example:
//localhost> /c0 show autorebuild
/c0 Auto-Rebuild Policy = on
/cx show unitstatus
This command presents a list of units, their types, capacity and status currently managed by the
specified controller /cx.
Example:
//localhost> /c2 show unitstatus
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-5 OK - - 64K 596.004 ON OFF
u1 RAID-0 OK - - 64K 298.002 ON OFF
u2 SPARE OK - - - 149.042 - OFF
u3 RAID-1 OK - - - 149.001 ON OFF
/cx show allunitstatus
This command presents a count of Total and Not Optimal units managed by the specified controller
/cx. See "Shell Object Messages" for more on Not Optimal definition.
Example:
//localhost> /c0 show allunitstatus
/c0 Total Optimal Units = 2
/c0 Not Optimal Units = 0
/cx show drivestatus
This command presents a list of drives, port assignment, vendor signature, size, status, and unit
membership/affiliation.
Example:
//localhost> /c0 show drivestatus
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u0 149.05 GB 312581808 3JS0TF14
p1 OK u0 149.05 GB 312581808 3JS0TETZ
p2 OK u1 149.05 GB 312581808 3JS0VG85
p3 OK u1 149.05 GB 312581808 3JS0VGCY
p4 OK u1 149.05 GB 312581808 3JS0VGGQ
p5 OK u2 149.05 GB 312581808 3JS0VH1P
p6 OK - 149.05 GB 312581808 3JS0TF0P
p7 OK - 149.05 GB 312581808 3JS0VF43
p8 OK - 149.05 GB 312581808 3JS0VG8D
p9 NOT-PRESENT - - - -
p10 NOT-PRESENT - - - -
p11 NOT-PRESENT - - - -
/cx show all
This command shows the current setting of all attributes.
/cx add type=<RaidType> disk=<p:-p> [stripe=Stripe] [noscan]
[group=<3|4|5|6|7|8|9|10|11|12|13|14|15|16>] [nocache] [autoverify] [noqpolicy] [ignoreECC]
[name=string] [storsave=<protect|balance|perform>] [v0=n]
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 rea-
sons. However, if there is no BBU available for the controller, a warning is sent to standard
error. 2) The default drive queuing policy is enabled, unless it is specifically set to disable
queuing by specifing noqpolicy. 3) The noqpolicy attribute is not applicable to the "spare"
unit. Specifying the noqpolicy attribute returns an error.
Since this command is by far the richest command, it deserves more details.
/cx is the controller name as in /c0, /c1, etc.
type=RaidType consists of logical unit type as in raid0, raid1, raid5, raid10, raid50, single,
spare, and raid6 (9650SE and higher only).
For example type=raid50.
The following table illustrates supported types and controller models.
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single | Raid6 |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
7K/8K | Y | Y | Y | Y | Y | Y | N | N | N |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
9K | Y | Y | Y | Y | N | Y | Y | Y | N |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
9650SE| | | | | | | | | |
and | Y | Y | Y | Y | N | Y | Y | Y | Y |
higher| | | | | | | | | |
------+-------+-------+-------+--------+------+-------+--------+--------+-------+
disk=p:-p consists of a list of ports (disks) to be used in the construction of the specified
unit type. One or more ports can be specified. Multiple ports can be specified using ":" or "-"
as port index separators. A dash indicates a range and can be mixed with ":". For example
disk=0:1:2-5:9:12 indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12.
stripe=Stripe consists of the stripe size to be used. The following table illustrates the sup-
ported and applicable stripes on unit types and controller models. Stripe size of units are in K
(kilo bytes).
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single | Raid6 |
------+---------+--------+--------+---------+------+-------+--------+--------+-------+
7K/8K | 64 | N/A | 64 | 64 | N/A | N/A | N/S | N/S | N/S |
| 128 | | | 128 | | | | | |
| 256 | | | 256 | | | | | |
| 512 | | | 512 | | | | | |
| 1024 | | | 1024 | | | | | |
------+---------+--------+--------+---------+------+-------+--------+--------+-------+
9K | 16 | N/A | 16 | 16 | N/A | N/A | 16 | N/A | |
| 64 | | 64 | 64 | | | 64 | | |
| 256 | | 256 | 256 | | | 256 | | |
------+---------+--------+--------+---------+------+-------+--------+--------+-------+
9650SE| 16 | N/A | 16 | 16 | N/A | N/A | 16 | N/A | |
| 64 | | 64 | 64 | | | 64 | | 64 |
| 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.
Recall that a RAID-50 is a multi-tier array. At the most bottom layer, N number of disks per
group are used to form the RAID-5 layer. These RAID-5 arrays are then integrated into a RAID-0.
This attribute allows you to specify the number of disks in the RAID-5 level. Valid values are 3,
4, 5, 6, 7 and 8.
Note that a sufficient number of disks are required for a given pattern or disk group. For
example, given 6 disks, specifying 3 will create two RAID-5. However given 12 disks, specifying
3 will create four RAID-5 under the RAID-0 level. Given 6 disks and grouping of 6 is not
allowed, as you'll basically be creating a RAID-5.
The default group varies based on number of disks. For 6 & 9 disks, default is group=3. For 8
disks, default is group=4. For 10 or 15 disks, default is group=5. For 12 or 16 disks, default
is group=4. For 14 disks, default is group=7. Case of 12 disks could be grouped with group=3,
group=4, or group=6. Group=4 was set by default as it provides best net capacity and perfor-
mance. 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 attribute instructs CLI disable the write cache on the newly created unit. Enabling
write cache increases performance at the cost of high-availability. No cache is recommended when
no BBU or UPS is installed.
autoverify attribute enables the autoverify 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. This feature is
not supported on model 7000/8000. On model 9000, JBOD autoverify attribute is not persistent
(does not survive reboots).
noqpolicy attribute instructs CLI to disable the qpolicy (drive queuing) on the newly created
unit. The default qpolicy is on (i.e., noqpolicy is not specified). For the spare unit, drive
queueing is not meaningful and the qpolicy cannot be set. During unit creation, specifying
noqpolicy for spare returns an error.
ignoreECC attribute enables the ignoreECC/OverwriteECC attribute on the unit that is to be cre-
ated. For more details on this feature, refer to "cx/ux set Commands" section of this document.
The following table illustrates the supported Model-Unit Type. This table only applies to set-
ting this feature at unit creation time. Generally ignoreECC applies to redundant units.
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single |
------+-------+-------+-------+--------+------+-------+--------+--------+
7K/8K | N | N | N | N | N | N | N | N |
------+-------+-------+-------+--------+------+-------+--------+--------+
9K | N | Y | Y | Y | N | N | Y | N |
------+-------+-------+-------+--------+------+-------+--------+--------+
name=string attribute allows user to name the new unit. The maximum characters allowed for the
string are 21. No space is allowed within the string. If user likes to use some special charac-
ters which the OS command shell reserves such as '<', '>', '!', and '&', etc in the name string,
the user has to use quote "" around the name string in order to bypass the command shell. User
can change the name of the unit any time after the unit creation. This is a feature for 9000 or
above series of controllers. Please refer to commands /cx/ux set name=sting for changing the
name and /cx/ux show name for checking.
storsave=protect|balance|perform attribute allows user to set the storsave policy of the new
unit. It is a 9KSX/SE only feature. Please refer to command /cx/ux set storsave=protect|bal-
ance|perform for detail.
v0=n attribute allows the user to set the size of the first volume of the new unit. The first
volume may be, but not necessarily, the boot LUN. The input is a positive integer n in units of
gigabytes (GB). If the input is less than or equal to zero, the unit is created with the first
volume "uncarved", that is, the size would be the entire array size.
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 the volume
size(s):
//localhost> /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 RAID-5 OK - - - 64K 1117.56
u0-0 DISK OK - - p2 - 372.519
u0-1 DISK OK - - p3 - 372.519
u0-2 DISK OK - - p4 - 372.519
u0-3 DISK OK - - p5 - 372.519
u0/v0 Volume - - - - - 10
u0/v1 Volume - - - - - 1107.56
/cx rescan [noscan]
This command instructs the controller to rescan all ports and reconstitute all units. The con-
troller will update its list of ports (attached disks), and visits every DCB (Disk Configuration
Block) in order to re-assemble its view and awareness of logical units. Any newly found unit(s)
or drive(s) will be listed. noscan is used to not inform the OS of the unit discovery. Default
is to inform the OS.
Example:
//localhost> /c1 rescan
Rescanning controller /c1 for units and drives ...Done.
Found following unit(s): [/c1/u3].
Found following drive(s): [/c1/p7, /c1/p8].
Note: Does not import non-JBOD on 7000/8000 models.
/cx commit
This command instructs the controller to commit its dirty DCBs to persistent storage (ie disks).
While controller is processing I/O requests against underlying disks, an in-transaction bit is
set. If a failure (such as power failure) is experienced, subsequent read from the disks, will
inform the controller that an un-clean shutdown took place. This command allows the end user to
complete all pending I/Os on disks and clear the in-transaction bit.
Typical application of this feature is when an application is using a given unit in raw mode
(such as databases) and user would like to shutdown the host (Including UPS post failure automa-
tions). This command can then expedite the process by instructing the controller to finish pend-
ing requests, clear DCB's in-transaction flag as we are going down.
Note that block devices (cooked devices) do not require this and clients of block devices (such
as file systems) will send its own shutdown request to the devices.
This command only applies to Windows operating system.
/cx flush
This command allows you to flush the write cache on all units associated with the /cx controller
/cx update fw=filename_with_path [force]
This command allows the download of the specified firmware image to the corresponding controller.
This command is for 9000 series controllers only.
fw=filename_with_path attribute allows the user to specify the firmware image file name along
with its path. Please note that filename_with_path could not have spaces in the directory names
of its path (as Windows would allow).
The new image specified by filename_with_path will be checked for compatibility with the current
controller, current driver and current application versions. Subsequently a recommendation is
given to the user followed by a prompt to continue. Once the user decides to proceed, the image
will be downloaded to the controller. However, a reboot is required for the new image to take
effect.
Example:
//localhost> /c2 update fw=/tmp/prom0006.img
Warning: We strongly recommend backing up your data before updating
the firmware. Updating the firmware can render the device driver
and/or management tools incompatible. It is recommended to have
a copy of current firmware image for rollbacks.
Examining compatibility data from firmware image and /c2 ... Done.
New-Firmware Current-Firmware Current-Driver Current-API
----------------------------------------------------------------------
FE9X 3.05.00.005 FE9X 3.05.00.005 2.26.04.007 2.01.00.008
Current firmware version is the same as the new firmware.
Recommendation: No need to update.
Given the above recommendation...
Do you want to continue ? Y|N [N]: y
Downloading the firmware from file /tmp/prom0006.img ... Done.
The new image will take effect after reboot.
force attribute is optional. With it the compatibility checks are bypassed.
/cx show alarms [reverse]
Asynchronous events 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 pro-
grams such as CLI and/or 3DMPlus. These events reflect warning, debugging and/or informative mes-
sages for end user.
Alarms generated on 7000/8000 models do not have dates, as such you'll see a '-' (read not-appli-
cable) in "Date" column. Also on 7000/8000 models, the alarm message, contain the severity as
well, hence the "Severity" column is showing a '-' as well.
This command displays all available alarms on a given controller. The default is to display the
most recent alarm or AEN message first. User can also use the [reverse] attribute to display the
most recent alarm or AEN message last.
Typical output looks like:
//localhost> /c1 show alarms reverse
Ctl Date Severity Message
----------------------------------------------------------------------------
c1 [Fri Nov 28 04:26:31 2003] ERROR (0x04:0x0002): Degraded unit detected: unit=0, port=2
c1 [Fri Nov 28 06:13:54 2003] INFO (0x04:0x000B): Rebuild started: unit=0
c1 [Fri Nov 28 06:30:35 2003] INFO (0x04:0x003B): Background rebuild paused: unit=0
c1 [Fri Nov 28 06:33:00 2003] ERROR (0x04:0x0002): Degraded unit detected: unit=0, port=0
c1 [Fri Nov 28 06:33:04 2003] ERROR (0x04:0x0002): Degraded unit detected: unit=0, port=4
c1 [Fri Nov 28 06:33:46 2003] INFO (0x04:0x000B): Rebuild started: unit=0
c1 [Fri Nov 28 06:37:58 2003] INFO (0x04:0x000B): Rebuild started: unit=0
c1 [Fri Nov 28 07:51:34 2003] INFO (0x04:0x0005): Background rebuild done: unit=0
c1 [Fri Nov 28 07:59:43 2003] INFO (0x04:0x0005): Background rebuild done: unit=0
c1 [Mon Dec 1 02:26:12 2003] ERROR (0x04:0x0002): Degraded unit detected: unit=0, port=3
/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 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 illustrated below.
$ tw_cli /c1 show rebuild
Rebuild Schedule for Controller /c1
========================================================
Slot Day Hour Duration Status
--------------------------------------------------------
1 Mon 2:00pm 10 hr(s) disabled
2 Thu 7:00pm 18 hr(s) disabled
3 - - - -
4 - - - -
5 - - - -
6 Mon 1:00am 4 hr(s) disabled
7 Sun 12:00am 1 hr(s) disabled
Status "disabled" indicates that the controller will not use the tabled schedules.
Note: The rebuild schedules are also applicable to initialization and migration processes.
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
========================================================
Slot Day Hour Duration Status
--------------------------------------------------------
1 Mon 2:00pm 10 hr(s) enabled
2 Thu 7:00pm 18 hr(s) enabled
3 - - - -
4 - - - -
5 - - - -
6 Mon 1:00am 4 hr(s) enabled
7 Sun 12:00am 1 hr(s) enabled
$ tw_cli /c1 show
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 verify
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 activity can be
managed by a set of commands including add, del, show and set a task. Background tasks have a
slot id, start day, hour, duration, and status attributes.
Verify activity attempts to verify all units based on their unit type. Verifying RAID-1 involves
checking that both drives contain the exact data. On RAID-5, 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).
This command displays the current verify background task schedule as illustrated below.
$ tw_cli /c1 show verify
Verify Schedule for Controller /c1
========================================================
Slot Day Hour Duration Status
--------------------------------------------------------
1 Mon 2:00am 4 hr(s) disabled
2 - - - -
3 Tue 12:00am 24 hr(s) disabled
4 Wed 12:00am 24 hr(s) disabled
5 Thu 12:00am 24 hr(s) disabled
6 Fri 12:00am 24 hr(s) disabled
7 Sat 12:00am 24 hr(s) disabled
Status "disabled" indicates that the controller will not use the tabled schedules.
/cx show selftest
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 activity can be
managed by a set of commands including add, del, show and set a task. Background tasks have a
slot id, start-day-time, duration, status attributes.
selftest activity provides two types of selftests; UDMA (Ultra Direct Memory Access) and SMART
(Self Monitoring Analysis and Reporting). Both self tests 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 illustrated 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:
$ tw_cli /c1 add rebuild=Sun:16:3
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 background verify task to be executed on day ddd (where ddd is Sun, Mon,
Tue, Wed, Thu, Fri, and Sat), at 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 "verify" background task description, see command /cx show verify.
For example:
$ tw_cli /c1 add verify=Sun:16:3
Will add a verify background task schedule to be executed on Sundays at 4:00 PM for a duration of
3 hours.
/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 provided. This command will fail if no (empty) slot is
available.
For "selftest" background task description, see command /cx show selftest.
For example:
$ tw_cli /c1 add selftest=Sun:16
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.
WARNING: If all timeslots are removed, be sure to also disable the schedule. Otherwise the
applicable background task will never occur.
/cx del selftest=slot_id
This command will remove (or unregister) the selftest background task in slot slot_id.
For "selftest" background task description, see command /cx show selftest.
For example:
$ tw_cli /c1 del selftest=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 rebuild background tasks on controller /cx. When
enabled, only tabled scheduled tasks will be followed (or used). Any previous on-demand back-
ground tasks will be ignored.
This command also allows you to set priority of rebuild vs I/O operations. Setting this value
to 1 implies that rebuilds should consume more resources (cpu time, I/O bandwidth) to complete
its task. Conversely setting this value to 5 implies that I/O has higher priority and rebuild.
This command applies to 7000, 8000, and 9000 models. 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 verify=enable|disable|1..5
This command will enable or disable all verify background tasks on controller /cx. When enabled,
only tabled scheduled tasks will be followed (or used). Any previous on-demand background tasks
will be ignored.
This command allows you to set priority of verification vs I/O operations. Setting this value to
1 implies fastest verify, and 5 implies fastest I/O. Note that this feature only applies to 9000
models.
For "verify" background task description, see command /cx show verify.
/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 (9000S only)
This command allows you to set a controller based 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, regard-
less 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 posi-
tive integer between 1 to the number of disks/ports supported on the controller (e.g. 4, 8, 12,
16). This policy is used to stagger spin ups of disks at boot time in order to spread the power
consumption on the power supply. For example, given a spin up policy of 2, the controller will
spin up two disks at a time, pause, and then spin up another 2 disks, 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 should spin up disks at boot time.
/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 carve-
size volumes and a remaining volume. Each volume can be treated as an individual disk with its
own file system. The default carvesize is 2 TB. This feature is useful for operating systems
limited to 2 TB filesystems.
For example a 3 TB array would be configured into a 2 TB and a 1 TB volumes with default carve-
size. 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 vol-
ume.
Example:
//localhost> /c0 set autocarve=on
Setting Auto-Carving Policy on /c0 to on ... Done.
/cx set carvesize=[1024..2048] (9KSX/SE/SA only)
This command allows you to set the carve size in GB. This feature works together with the auto-
carve 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 candidate of a 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 off, spares are the only candidates for rebuild operations.
Example:
//localhost> /c0 set autorebuild=on
Setting Auto-Rebuild Policy on /c0 to on ... Done.
/cx set autodetect=on|off disk=<p:-p>|all (9000 series)
This command is associated with the stagger spin-up feature during hot-plug. With stagger spin-
up enabled (see command /cx set spinup and /cx set stagger), during reset or power on, the con-
troller will try to detect all drives that are present and spin them up staggered in time, allow-
ing 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 setting. It should be
set to off to initiate the sequence for the stagger spin-up during hot-plug process. After the
drives are inserted or re-inserted to the ports (as specified in the second attribute decribed
below), it should be set back to on to complete the configuration process for the controller to
initiate the drive spin-up.
disk=<p:-p>|all attribute specifies one or many disks (i.e., drives or ports). If a port is
empty (i.e., no drive inserted), the echo message of the command refers to a port, and if there
is already a drive inserted the message refers to a disk. The example below shows that auto
detect has been set to off to initiate stagger spin-up during hot-plug, where port 3 was empty
and ports 5 and 6 had drives inserted.
//localhost>> /c0 set autodetect=off disk=3:5-6
Setting Auto-Detect on /c0 to [off] for port [3] and for disk [5,6]... Done
If "disk=all", then all of the drives or ports for that controller are specified. for example:
//localhost>> /c0 set autodetect=off disk=all
Setting Auto-Detect on /c2 to [off] for all disks/ports... Done.
To illustrate how the command is used, here is a usage scenario:
1. Issue command (set autodetect=off) to disable automatic detection of the
ports for staggered spin-up.
2. Pull out the drives of the specified ports (if not empty).
3. Replace the drives previously removed at the ports specified.
4. Issue command (set autodetect=on) to enable auto detect of the ports with
the newly inserted drives.
The above procedure would spin-up the newly inserted drives in a staggered manner. Please note
that the command takes longer to complete for ports that do not have drives inserted.
/cx start mediascan
This command applies to 7000/8000 controllers. It provides media scrubbing for validating func-
tionality 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 func-
tionality of a disk. This includes bad block detection and remapping, etc. The commands stops a
media scan operation on the specified controller /cx.
Logical Disk Object Messages
Logical Disk Object Messages are commands (a.k.a. methods/messages) that are sent to an instance
of a Logical Disk (a.k.a. unit) such as /c0/u0.
Note that in the output of unit information tables that follows, the column "Port" may be "VPort"
depending on the applicable controller.
/cx/ux show
This command shows summary information on the specified unit /cx/ux. If the unit consists of
sub-units as with the case of RAID-10, and RAID-50 arrays, then each sub-unit is further pre-
sented. If the Auto-Carving policy was on at the time the unit was created and the unit is over
the carve size (default is 2 TB - 1), multiple volumes will be created and will be displayed at
the end of the summary information.
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.
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
/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: initializes-
tatus, name(9000 series), qpolicy(9KSX/SE/SA Only), rebuildstatus, serial(9000 series), status,
storsave(9KSX/SE/SA Only), verifystatus, volumes(9000 series), autoverify, cache, ignoreECC, and
identify. The attributes volumes, name, serial, autoverify, and ignoreECC are applicable to 9000
series controllers; and the attributes qpolicy, storsave, and identify are only applicable to
9KSX/SE/SA controllers.
/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:
//localhost> /c0/u5 show rebuildstatus
/c0/u5 is not rebuilding, its current state is OK
/cx/ux show verifystatus
This command presents the verifystatus (if any) of the specified unit.
Example:
//localhost> /c0/u5 show verifystatus
/c0/u5 is not verifying, its current state is OK
/cx/ux show initializestatus
This command 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:
//localhost> /c0/u5 show storsave
/c0/u5 Command Storsave Policy = protect
/cx/ux show identify (9KSX/SE/SA only)
This command is related to the unit set identify command and it shows the identify status of the
specified unit.
For example: Example:
//localhost> /c0/u0 show identify
/c0/u0 Identify status = on.
/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
This command presents the current write cache state of the specified unit.
Example:
//localhost> /c0/u0 show cache
/c0/u0 Cache State = on
/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 all
This command shows the current setting of all above attributes.
If the Auto-Carving policy was on at the time the unit was created and the unit is over the carve
size (default is 2 TB - 1), multiple volumes will be created and will be displayed at the end of
the summary information.
Example:
//localhost> /c0/u1 show all
/c0/u1 status = OK
/c0/u1 is not rebuilding, its current state is OK
/c0/u1 is not verifying, its current state is OK
/c0/u1 is not initializing, its current state is OK
/c0/u1 volume(s) = 2
/c0/u1 name = 1234567
/c0/u1 serial number = C6CPR7JMF98DA8001DF0
//localhost> /c0/u1 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u1 RAID-0 OK - - - 64K 3576.06
u1-0 DISK OK - - p0 - 298.01
u1-1 DISK OK - - p1 - 298.01
u1-2 DISK OK - - p2 - 298.01
u1-3 DISK OK - - p3 - 298.01
u1-4 DISK OK - - p4 - 298.01
u1-5 DISK OK - - p5 - 298.01
u1-6 DISK OK - - p6 - 298.01
u1-7 DISK OK - - p7 - 298.01
u1-8 DISK OK - - p8 - 298.01
u1-9 DISK OK - - p9 - 298.01
u1-10 DISK OK - - p10 - 298.01
u1-11 DISK OK - - p11 - 298.01
u1/v0 Volume - - - - - 2047.00
u1/v1 Volume - - - - - 1529.06
/cx/ux remove [noscan] [quiet]
This command allows you to remove (or export) a unit. Exporting a unit will instruct the firmware
to remove the specified unit from its pool of managed units, but retains the DCB (Disk Configura-
tion 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 man-
aged disks. In another words, once the unit is deleted, all the data on the unit can not be
recovered. noscan is used to not inform the OS of this change. Default is to inform the OS. The
quiet option is for non-interactive mode.
Use caution when using this command. This is a destructive command and should be used with
extreme care. Units that are currently in use or mounted should not be deleted.
/cx/ux start rebuild disk=p [ignoreECC]
This command allows you to rebuild a DEGRADED unit by using the specified disk=p. Rebuild only
applies to redundant arrays such as RAID-1, RAID-5, RAID-10 and RAID-50. During rebuild, bad
sectors on the source disk will cause the rebuild to fail. You can allow for the operation to
continue via ignoreECC. Rebuild process is a background task and will change the state of a unit
to REBUILDING. Various show commands also show a percent completion as rebuilding progresses.
Note that the disk to be used to rebuild a unit, must be a SPARE or unconfigured disk.
/cx/ux start verify
This command starts a background verification process on the specified unit /cx/ux. The following
shows the supported matrix as a function of controller model and logical unit type. N/A (Not
Applicable) refers to cases where the given logical unit type is not supported on that controller
model.
Model | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare |
------+-------+-------+-------+--------+--------+--------+------+-------+
7K/8K | No | Yes | Yes | Yes | N/A | N/A | No | No |
------+-------+-------+-------+--------+--------+--------+------+-------+
9K | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
------+-------+-------+-------+--------+--------+--------+------+-------+
Note that if subsequent to this command, one enables the background verify task to follow the
scheduled slots, then this on-demand task will be paused until the next scheduled timeslot.
/cx/ux pause rebuild
This command allows you to pause the rebuild operation on the specified REBUILDING unit /cx/ux.
This feature is intended for model 7000 and 8000 only. Model 9000 has an on-board scheduler where
rebuild operations can be scheduled to take place at specified start and stop times.
Rebuild pause function is provided to enable 7000/8000 users to achieve functionality with use of
OS provided schedulers such as cron(8) or, at(1) in Linux or user supplied programs.
/cx/ux resume rebuild
This command allows you to resume the rebuild operation on the specified unit /cx/ux. This fea-
ture is intended for model 7000 and 8000 only. Model 9000 has an on-board scheduler where
rebuild operations can be scheduled to take place at specified start and stop times.
Rebuild resume function is provided to enable 7000/8000 users to achieve similar functionality
with use of OS provided schedulers such as cron(8) or, at(1) in Linux or user supplied programs.
/cx/ux stop verify
This command stops a background verification process on the specified unit /cx/ux. The following
shows the supported matrix as a function of controller model and logical unit type. N/A (Not
Applicable) refers to cases where the given logical unit type is not supported on that controller
model.
Model | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare |
------+-------+-------+-------+--------+--------+--------+------+-------+
7K/8K | No | Yes | Yes | Yes | N/A | N/A | No | No |
------+-------+-------+-------+--------+--------+--------+------+-------+
9K | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
------+-------+-------+-------+--------+--------+--------+------+-------+
Note that if subsequent to this command, one enables the background verify task to follow the
scheduled slots, then this on-demand task will be paused until the next scheduled timeslot.
/cx/ux flush
This command allows you to flush the write cache on the specified unit /ux associated with con-
troller /cx. Note that this command does not apply to spare unit types.
/cx/ux set autoverify=on|off
This command allows you to turn on/off the autoverify operation on a specified unit /cx/ux. Once
the autoverify=on, the RAID firmware will pick a time to start the verify process on the unit.
If the allocated schedule windows is enabled, the verify process becomes active during the sched-
uled windows. Otherwise, the firmware will decide when the verify needs to be paused or
restarted again before it completes.
You can use the show verify command to display the existing schedule windows. The autoverify
operation is a continuous verify operation, which takes place within the existing schedule win-
dows (displayed with /cx show verify) if the schedule is enabled. While the "/cx show verify"
command allows you to see the time for the verify operation, this command allows you to enable or
disable the autoverify operation on the specified unit. This feature only applies to 9000 mod-
els.
/cx/ux set cache=on|off [quiet]
This command allows you to turn the write cache on a specified unit /cx/ux, on or off. This fea-
ture is supported on both 7000/8000 and 9000 models. The quiet option is for non-interactive
mode. It can be used in conjunction with set cache=on command when the controller has no BBU
installed. The following is the Raid Type-Model support matrix.
Model | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare |
------+-------+-------+-------+--------+--------+--------+------+-------+
7K/8K | Yes | Yes | Yes | Yes | N/A | N/A | Yes | No |
------+-------+-------+-------+--------+--------+--------+------+-------+
9K | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
------+-------+-------+-------+--------+--------+--------+------+-------+
/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
This command allows you to set the ignoreECC policy for a given unit such that during rebuild of
the specified unit, which could begin automatically (if the unit is degraded and spare has been
defined) or manually, to be applied to the rebuild operation. Setting overwriteECC to on means
ignoreECC. This feature only applies to 9000 models.
/cx/ux set name=string (9000 series)
This command allows you to name the unit to an arbitrary name upto 21 characters. No space is
allowed within the string. If user likes to use some special characters which the OS command
shell reserves such as '<', '>', '!', and '&', etc in the name string, the user has to use quote
"" around the name string in order to bypass the command shell. Users can use this name in
conjunction with the unit serial number (which created at the unit creation time) to cross refer-
ence 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 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 set-
ting.
protect -- provide the maximum data protection among the controller settings. When user sets
storsave to protect mode, it means :
1. "Write Cache" will be disabled when the unit becomes "DEGRADED",
2. all data flushing from controller cache will be flushed to media, and
3. incoming FUA (Force Unit Access) host request will be ignored if a BBU is installed and
enabled; Otherwise, will be honored.
perform -- provide the maximum performance and less data protection among the the controller set-
tings. 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 protection 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 capac-
ity), or change the stripe size.
The unit that results from the migration (destination unit) is subject to similar rules and poli-
cies that apply when creating a new unit. For example, a valid number of disks and parameters
must be specified. The destination unit must use all source disks and potentially augment the
number of disks in the disk=p:-p disk list. Unspecified parameters are assigned default values
(stripe size of 64K, write cache enabled, autoverify disabled, and ignoreECC disabled).
The unit to be migrated (source unit) must be in a normal state (not degraded, initializing, or
rebuilding) before the migration. If the source unit is of type RAID-1 and the destination unit
is of type single, the disk-specifier of the migration command [disk=p:-p] is actually not
optional and must not be included in the command. The drives in the RAID-1 array would become
multiple units of type single after the migration, and the source drives are the destination
drives. Specifying more drives with the "disk=" option would return an error.
Both source unit name and serial number will be carried over to the destination unit. However,
the RAID-1 to single migration path is a special case. In this case, the migrate command splits
both drives into two identical single disks. The source unit name will be duplicated on the des-
tination units, or single disks, but the source unit serial number will not be carried over to
new unit. The new destination unit will have its own serial number.
type=RaidType consists of the destination unit RAID type as in raid0, raid1, raid5, raid10,
raid50, raid6, or single.
For example "type=raid5" indicates the destination unit is RAID-5.
The following table illustrates valid migration paths:
Src/Dst | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare | Raid6 |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid0 | Y | N | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid1 | Y | N | Y | Y | Y | Y | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid5 | Y | N | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid10 | Y | N | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid50 | Y | N | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Single | Y | Y | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
JBOD | N | N | N | N | N | N | N | N | N |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Spare | N | N | N | N | N | N | N | N | N |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Raid6 | Y | N | Y | Y | Y | N | N | N | Y |
--------+-------+-------+-------+--------+--------+--------+------+-------+-------+
Note: You can only migrate a unit to a RAID level that has the same or larger capacity as the
exisiting one. A four-drive RAID-5 unit can migrate to a four-drive RAID-0, but a four-drive
RAID-0 unit cannot migrate to a four-drive RAID-5, without adding another drive, due to the need
for additional storage capacity for parity bits.
disk=p:-p consists of a list of ports or vports (disks) to be used in addition to the source
disks in the construction of the destination unit. One or more ports can be specified. Multiple
ports can be specified using ":" or "-" as port index separators. A dash indicates a range and
can be mixed with ":". For example disk=0:1:2-5:9:12 indicates port 0, 1, 2 thru 5 (inclusive), 9
and 12.
group=3|4|5|6|7|8|9|10|11|12|13|14|15|16 is only applicable to type=raid50 which consists of a
number of disks per group. Recall that a RAID-50 is a multi-tier array. At the most bottom
layer, N number of disks per group are used to form the RAID-5 layer. These RAID-5 arrays are
then integrated into a RAID-0. This option allows you to specify the number of disks in the
RAID-5 level. Valid values are 3, 4, 5 and 6. For example group=3 indicates 3 disks of RAID-5 at
the bottom layer of RAID-50.
Note: You can have a maximum of 4 subunits in a RAID-50 unit.
Note that a sufficient number of disks are required for a given pattern or disk group. For exam-
ple, given 6 disks, specifying 3 will create two RAID-5. However given 12 disks, specifying 3
will create four RAID-5 under the RAID-0 level. Given 6 disks and grouping of 6 is not allowed,
as you'll basically be creating a RAID-5.
The default disk group varies based on number of disks. For 6 & 9 disks, default is group=3. For
8 disks, default is group=4. For 10 or 15 disks, default is group=5. For 12 or 16 disks, default
is group=4. For 14 disks, default is group=7. Case of 12 disks could be grouped with group=3,
group=4, or group=6. Group=4 was set by default as it provides best net capacity and perfor-
mance. Case of 15 disks could be grouped with group=3 or group=5. And case of 16 disks could be
grouped with group=4 and group=8.
Note that RAID-10 always has group=2, so an attribute specifying its group is not necessary.
Stripe consists of the logical unit stripe size to be used. The following table illustrates the
supported and applicable stripes on the respective unit types and controller models. Stripe size
units are in KB (kilobytes).
Model | Raid0 | Raid1 | Raid5 | Raid10 | JBOD | Spare | Raid50 | Single |
------+---------+--------+--------+---------+------+-------+--------+--------+
9K | 16 | N/A | 16 | 16 | N/A | N/A | 16 | N/A |
| 64 | | 64 | 64 | | | 64 | |
| 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 creat-
ing block special devices such as /dev/sdb and /dev/sdc as some implementations might create nam-
ing fragmentation and a moving target.
nocache instructs CLI to disable the write cache on the migrated unit. Enabling write cache
increases performance, but at the cost of potential data loss in the event of sudden power loss
(unless a BBU or UPS is installed). By default the cache is enabled. Unless there is a BBU or
UPS installed, to avoid the possibility of data loss in the event of sudden power loss, it is
recommended that nocache be specified.
autoverify enables the autoverify attribute on the unit to be migrated. For more details on this
feature, refer to "cx/ux set autoverify" section of this document.
Migration Process. In all cases of migration, the background migration process must be completed
before the newly sized unit is available for use. You can continue using the original unit dur-
ing this time. Once the migration is finished, a reboot will be required if you are booted from
the unit. For secondary storage, depending on your operating system, you may need to first
unmount the unit, then use CLI to 'remove' and 'rescan' the unit so that the operating system can
see the new capacity, and then remount the unit.
You may also need to resize the file system or add a new partition. For instructions, consult
the documentation for your operating system.
Note: It is important that you allow migration to complete before adding drives to the unit or
move it to another controller. Making any physical changes to the unit during migration may
cause the migration to stop, and can jeopardize the safety of your data.
Examples. The two examples which follow show the usage of this command for splitting a mirror
and for capacity expansion, respectively. Following those are sample outputs of the migrate
function. After which example outputs showing the special case are presented.
Example of split mirror:
//localhost> /c1/u3 migrate type=single
Sending migration message to /c1/u3 ... Done.
The source unit u3 is a TWINSTOR or RAID-1, using the migrate command splits u3 to u3 and ux,
each with the RAID type of Single.
Example of capacity expansion:
//localhost> /c0/u3 migrate type=raid10 disk=10-11 stripe=16
Sending migration message to /c0/u3 ... Done.
The source unit is u3 and the destination unit is RAID-10 with disks 10 and 11 in addition to the
disks in the existing unit u3.
The following is an example of how migrating units are displayed. In this example, the set of
reports indicate that /c0/u3 is a migrating unit with 39% completion. The "/c0/u3 show" command
shows that the source unit is su3 and is of type RAID-1, and the destination unit du3 is of type
RAID-10.
3ware CLI> /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-5 OK - - 64K 596.004 ON OFF
u2 SPARE OK - - - 149.042 - OFF
u3 Migrator MIGRATING - 39 - 149.001 ON OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u0 149.05 GB 312581808 WD-WCANM1771318
p1 OK u0 149.05 GB 312581808 WD-WCANM1757592
p2 OK u0 149.05 GB 312581808 WD-WCANM1782201
p3 OK u0 149.05 GB 312581808 WD-WCANM1753998
p4 OK u2 149.05 GB 312581808 WD-WCANM1766952
p5 OK u3 149.05 GB 312581808 WD-WCANM1882472
p6 OK u0 149.05 GB 312581808 WD-WCANM1883862
p7 OK u3 149.05 GB 312581808 WD-WCANM1778008
p8 OK - 149.05 GB 312581808 WD-WCANM1770998
p9 NOT-PRESENT - - - -
p10 OK u3 149.05 GB 312581808 WD-WCANM1869003
p11 OK u3 149.05 GB 312581808 WD-WCANM1762464
3ware CLI> /c0/u3 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u3 Migrator MIGRATING - 39 - - -
su3 RAID-1 OK - - - - 149.001
su3-0 DISK OK - - p5 - 149.001
su3-1 DISK OK - - p7 - 149.001
su3/v0 Volume - - - - - 149.001
du3 RAID-10 OK - - - 16K 298.002
du3-0 RAID-1 OK - - - - -
du3-0-0 DISK OK - - p5 - 149.001
du3-0-1 DISK OK - - p7 - 149.001
du3-1 RAID-1 OK - - - - -
du3-1-0 DISK OK - - p10 - 149.001
du3-1-1 DISK OK - - p11 - 149.001
du3/v0 Volume - - - - - 149.001
Please note that the migration path of raidtype Single to RAID-1 is a special case. Since the
single unit would become a mirrored array, technically this is not a migration. As a result this
command shows a different status than other migration paths. In addition, the status of the
newly specified disk would show DEGRADED until the "migration" is complete.
For example, below is a system with two migrating units, /c0/u0 and /c0/u1. u0 is migrating from
a RAID-10 to a RAID-0 array, while u1 is migrating from Single to a RAID-1, initiated by the fol-
lowing commands:
/c0/u0 migrate type=raid0
and
/c0/u1 migrate type=raid1 disk=5
Note the difference in 'UnitType' and 'Status' of u0 and u1, even though they are both migrating
units.
3ware CLI> /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 Migrator MIGRATING - 26 - 298.002 ON OFF
u1 RAID-1 REBUILD-PAUSED 0 - - 372.519 OFF OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u0 149.05 GB 312581808 WD-WCANM1883862
p1 OK u0 149.05 GB 312581808 WD-WCANM1754124
p2 OK u0 372.61 GB 781422768 WD-WMAMY1661939
p3 OK u0 372.61 GB 781422768 WD-WMAMY1579179
p4 OK u1 372.61 GB 781422768 WD-WMAMY1662720
p5 DEGRADED u1 372.61 GB 781422768 WD-WMAMY1576310
p6 NOT-PRESENT - - - -
p7 NOT-PRESENT - - - -
3ware CLI> /c0/u3 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 Migrator MIGRATING - 26 - - -
su0 RAID-10 OK - - - 64K 298.002
su0-0 RAID-1 OK - - - - -
su0-0-0 DISK OK - - p0 - 149.001
su0-0-1 DISK OK - - p1 - 149.001
su0-1 RAID-1 OK - - - - -
su0-1-0 DISK OK - - p2 - 149.001
su0-1-1 DISK OK - - p3 - 149.001
su0/v0 Volume - - - - - 298.002
du0 RAID-0 OK - - - 64K 596.004
du0-0 DISK OK - - p3 - 149.001
du0-1 DISK OK - - p2 - 149.001
du0-2 DISK OK - - p1 - 149.001
du0-3 DISK OK - - p0 - 149.001
du0/v0 Volume - - - - - N/A
3ware CLI> /c0/u1 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u1 RAID-1 REBUILD-PAUSED 0 - - - 372.519
u1-0 DISK OK - - p4 - 372.519
u1-1 DISK DEGRADED - - p5 - 372.519
u1/v0 Volume - - - - - 372.519
Port Object Messages
Port Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a
disk which attaches to a port or vport such as /c0/p0. Note: All references of port also
applies to vport for the commands in this section.
/cx/px show
This command shows summary information on the specified disk attached to port /cx/px. Typical
information looks like:
Example:
//localhost> /c0/p5 show
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 Western 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 command, or the "show all" command.) Please also note
that the port handle as a virtual port is indicated by the heading or column "VPort".
/cx/px show Attribute Attribute ...
This command shows the current setting of the given attribute(s) on the specified port or disk.
One or many attributes can be requested. Invalid attribute will terminate the loop. Possible
attributes are: capacity, firmware, identify(9KSX/SE/SA only), lspeed(9KSX/SE/SA only), model,
ncq(9KSX/SE/SA only), serial, smart, and status.
/cx/px show status
This command presents the status of the specified port.
Note: The status returned pertains to the drive of the specified port only. If the drive is the
degradation point of the unit that is degraded, the status of this command, being the drive sta-
tus, would not indicate that. For the unit status and ports associated, please use the command
"/cx show unitstatus" or "/cx show".
Example:
//localhost> /c0/p5 show status
/c0/p5 Status = OK
/cx/px show model
This command presents the model of the specified port.
Example:
//localhost> /c0/p5 show model
/c0/p5 Model = WDC WD1600BB-00DAA0
/cx/px show serial
This command presents the serial number of the specified port.
Example:
//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 hard disk vendors.
Example:
//localhost> /c0/p5 show capacity
149.05 GB (312581808)
/cx/px show smart
This command extracts SMART (Self Monitoring Analysis and Reporting) data from the specified
disk. Note that this data is actually extracted live from the disk; as such this command could be
used to get most recent data about presence or lack of a disk. Be aware that extracting SMART
data will burden the 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 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-intro-
duce) 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 acti-
vates 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.
Phy Object Messages
Phy Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a con-
troller phy such as /c0/phy0.
/cx/phyx show (9690SA only)
This command presents a summary report on the specified phy. The link speed of the phy is shown
in three columns: Supported, Enabled, and Control. The Supported and Enabled values are set for
the phy and are not changeable. The Control value is the link speed that may be set with the
'/cx/phyx set link' command. The default is 'auto'.
Example:
//localhost> /c3/phy0 show
Device --- Link Speed (Gbps) ---
Phy SAS Address Type Device Supported Enabled Control
-----------------------------------------------------------------------------
phy0 2007020800153811 SATA 1 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 control of the phy. The possible values are auto, 1.5, and 3.0
for SATA, and auto and 3.0 for SAS. The units are in Gigabits per second (Gbps).
//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/messages) that are sent to
an instance of a BBU such as /c0/bbu. This object is only available on 9000S 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
---------------------------------------------------------------------------
bbu On No Testing OK OK 72 01-Jul-2004
Indicates the date the battery capacity was last measured is 01-Jul-2004. The battery is esti-
mated to last for 72 hours from the last tested date. The BBU unit is currently testing the bat-
tery. Both voltage and temperature are normal. And the BBU is not ready to backup the write
cache on the controller due to the testing.
/cx/bbu show Attribute Attribute ...
This command shows the current setting of the given attribute(s) on the BBU board. One or many
attributes can be requested. Invalid attribute will terminate the loop. Possible attributes are:
batinst, bootloader, cap, fw, lasttest, pcb, ready, serial, status, 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 complete. During the
test, the BBU is not capable of backup operation and the write cache of the applicable RAID
units are also disabled. If the test is completed with no error and the BBU returns back to
WeakBat or OK state, the write cache will be resumed. If a Fault, Failed or an Error occurs
during the test, the write cache remains at the disabled state until the problem is fixed.
Charging
BBU is currently charging the battery. The charging is started automatically by the BBU
whenever necessary. During the charging, the BBU is not capable of backup operation and the
write cache is disabled. Once charging is completed and the BBU returns back to OK status,
the write cache will be resumed. If a FAULT or an ERROR occurs during the test, the write
cache remains at the disabled state until the problem is fixed.
Fault
A battery fault is detected. At this state, the BBU is not capable of backup operation and
the write cache is disabled. We recommend you to replace the battery and/or the BBU board to
fix the problem as soon as possible so that the write cache will be enabled again.
Error
Other BBU error is detected. At this state, the BBU is not capable of backup operation and
the write cache is disabled. We recommend you to replace the battery and/or the BBU board to
fix the problem as soon as possible so that the write cache will be enabled again.
Failed
The battery failed a test. At this state, the BBU is not capable of backup operation and the
write cache is disabled. We recommend you to replace the battery and/or the BBU board to fix
the problem as soon as possible so that the write cache will be enabled again.
WeakBat
BBU is functioning normally which means it is online and capable of backing up the write
cache. But the battery is weak and should be replaced.
OK
BBU is ready, online and capable of backing up the write cache.
-
Battery is not present or BBU unit is not installed.
/cx/bbu show batinst
This command shows the date when the current battery was installed.
/cx/bbu show lasttest
This command shows the date the battery capacity was last measured.
/cx/bbu show volt
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 operat-
ing 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 operation 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.
Check with the alarms command, AEN (Asynchronous Event Notification) messages are also generated
by controllers to notify user the status of the command.
Note: The test cannot be terminated before it completes.
/cx/bbu enable
This command enables the BBU detection on the controller. And the controller will utilize BBU
functionality in the event of power failure if BBU is there and ready.
/cx/bbu disable [quiet]
This command disables the BBU detection on the controller. In this situation, the controller
ignores the existence of the BBU when the BBU detection is disabled. 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 Services Commands
The Enclosure Services Commands are a set of methods and messages associated with the enclosure
object and the enclosure elements objects of the enclosure. They provide information about the
enclosure and its elements, as well as identification of the enclosure and element objects in the
enclosure system.
Enclosure Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of
an enclosure such as e0. The enclosure element object messages are commands sent to an instance
of the enclosure element such as fan0. The subsections which follow describe the commands of the
enclosure and the enclosure elements. The latter includes commands for the slot, fan, tempera-
ture sensor, and power supply elements.
The following commands support the 9690SA controller and the SES-2 protocol.
/cx/ex show
This command shows summary information on the specified enclosure /ex. This report consists of
several parts, depending on the available elements of the enclosures. Typically, the summary
consists of the Enclosure section listing the set of enclosures, a Fan section listing the set of
fans, a Temperature Sensor section listing of the set of temperature sensors and a Slot section
listing the set of slots.
Typical output looks like:
//localhost> /c0/e0 show
Encl Status
---------------------------
/c0/e0 -
Fan Status State Step RPM Identify
------------------------------------------------------------
fan0 OK ON 1 2670 Off
fan1 OK ON 1 9500 Off
fan2 OK ON 1 8540 Off
fan3 OK ON 1 2830 Off
fan4 OK ON 1 9120 Off
fan5 OK ON 1 8330 Off
TempSensor Status Temperature Identify
--------------------------------------------------------
temp0 OK 41C(105F) Off
temp1 OK 38C(100F) Off
temp2 OK 34C(93F) Off
temp3 OK 38C(100F) Off
temp4 OK 38C(100F) Off
temp5 OK 34C(93F) Off
temp6 NOT-INSTALLED - Off
temp7 NOT-INSTALLED - Off
PowerSupply Status State Voltage Current Identify
---------------------------------------------------------------------------
pwrs0 OK on OK OK Off
pwrs1 OK on OK OK Off
Slot Status (V)Port Identify
--------------------------------------------------
slot0 OK /c0/p0 Off
slot1 NO-DEVICE - Off
slot2 OK /c0/p1 Off
slot3 OK /c0/p2 Off
slot4 OK /c0/p3 Off
slot5 OK /c0/p4 Off
slot6 OK /c0/p5 Off
slot7 OK /c0/p6 Off
slot8 OK /c0/p7 Off
slot9 OK /c0/p8 Off
slot10 OK /c0/p9 Off
slot11 NO-DEVICE - Off
/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.
Example:
//localhost> /c0/e0 show controllers
/c0/e0 connects to controller /c0
/cx/ex show slots
This command reports a summary of slots with their respective information for the specified
enclosure.
Example:
//localhost> /e0 show slots
Slot Status (V)Port Identify
----------------------------------------------------
slot0 OK /c0/p0 No
slot1 OK /c0/p1 Yes
slot2 NO-DEVICE - No
slot3 NO-DEVICE - No
/cx/ex show fans
This command reports a summary of fans with their respective information for the specified enclo-
sure.
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 temp
This command reports a summary of temperature sensors with their respective information for the
specified enclosure.
Example:
//localhost> /c0/e0 show temp
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 a summary of power supplies with their respective information for the speci-
fied enclosure.
Example:
//localhost> /c0/e0 show pwrs
PowerSupply Status State Voltage Current Identify
---------------------------------------------------------------------------
pwrs0 OK on OK OK Off
pwrs1 OK on OK OK Off
/cx/ex show all
This command shows the current setting of all attributes.
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
is 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 that column would
be indicated with a dash (-). The next column shows whether the specified slot has been identi-
fied.
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.
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.
Setting it on would blink the LED of the specified drive slot. For example:
//localhost> /c0/e0/slot1 set identify=on
Setting Slot Identify on /c0/e0/slot1 to [on] ... Done.
Enclosure Element Fan
The enclosure fans commands provide information about the fan elements in the enclosure unit.
/cx/ex/fanx show
This command shows information about the specified fan element.
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 fan element.
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 fan element by setting the identify attribute to either on
or off. Setting it on would blink the LED of the specified fan element.
Example:
//localhost> /c0/e0/fan1 set identify=on
Setting Fan Identify on /c0/e0/fan1 to [on] ... Done.
Enclosure Element Temperature Sensor
The enclosure temperature sensor commands provide information about the temperature sensor ele-
ments in the enclosure unit.
/cx/ex/tempx show
This command shows information about the specified temperature sensor element. The possible sta-
tus values are OK, OVER-WARNING, OVER-FAIL, UNDER-WARNING, UNDER-FAIL, where OVER denotes over-
temperature and UNDER denotes under-temperature.
Example:
//localhost> /c0/e0/temp0 show
TempSensor Status Temperature Identify
--------------------------------------------------------
temp0 OK 42C(107F) Off
/cx/ex/tempx show identify
This command shows the identify status of the specified temperature sensor element of the speci-
fied enclosure.
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 temperature sensor element by setting the identify
attribute to either on or off. Setting it on would blink the LED i associated with the specified
temperature element. For example:
//localhost> /c0/e0/temp1 set identify=on
Setting Temperature Sensor Identify on /c0/e0/temp1 to [on] ... Done.
Enclosure Element Power Supply
The enclosure power supply commands provide information about the power supply elements in the
enclosure unit.
/cx/ex/pwrsx show
This command shows information about the specified power supply element. The possible status
values are OK, FAIL, NOT-INSTALLED, and OFF. The voltage and current columns indicate the
threshold voltage and current status. The possible values for Voltage are OK, OVER-VOLTAGE, and
UNDER-VOLTAGE. The possible values for Current are OK and OVER-CURRENT. In either case, OVER-
means over the set threshold of the voltage or current.
Example:
//localhost> /c0/e0/pwrs0 show
PowerSupply Status State Voltage Current Identify
---------------------------------------------------------------------------
pwrs0 OK on OK OK Off
/cx/ex/pwrsx show identify
This command shows the identify status of the specified power supply element.
Example:
//localhost> /c0/e0/pwrs0 show identify
/c0/e0/pwrs0 Identify status = off
/cx/ex/pwrsx set identify=on|off
This command identifies the specified temperature sensor element by setting the identify
attribute to either on or off. Setting it on would blink the LED associated with the specified
temperature element.
Example:
//localhost> /c0/e0/pwrs1 set identify=on
Setting Power Supply Identify on /c0/e0/pwrs1 to [on] ... Done.
Help Commands
This command set provides brief on-line help. At top level of the command set, it is considered
to be in the Shell Object. The Shell object has focus, show, flush, rescan, and commit commands.
In addition to the Shell Object, we also have other objects such as /cx, /cx/ux, /cx/px, /cx/bbu,
and /cx/ex. Using the help command on objects, the help command shows all possible sub-commands
associated with the object.
For example: help on the controller object /cx, will display all the sub-commands associated with
the controller /cx.
//localhost> help /cx
/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(9000S 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 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)] [v0=n] (n=size of first volume in GB)
[autoverify] [noqpolicy] [ignoreECC]
[storsave=<protect|balance|perform>] (9KSX/SE/SA)
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 (9000S 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..2048] (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 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 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.
However, user can also get help with "?" or "help" as the user progresses with the specific
object or a command after an object.
For example: As the user progresses to '/c0 show' and needs help on a specific attribute syntax,
he or she can use '?' to get help as following:
//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(9000S 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)
The following is a list of the Help Commands. A brief description follows 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.
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.
help show
This command provides specific show related help, illustrating various ways to use the show com-
mand. It provides reports on Controllers, Units and Drives. See the "Shell Object Messages" sec-
tion for more on show.
help flush
This command provides specific flush related help, illustrating various ways to use the flush
command. See the "Shell Object Messages" section for more.
help rescan
This command provides specific rescan related help, illustrating various ways to use the rescan
command. See the "Shell Object Messages" section for more.
help update
This command provides specific update related help. See the "Shell Object Messages" section for
more.
help commit
This command provides specific commit related help, illustrating various ways to use the commit
command. See the "Shell Object Messages" section for more.
help focus
This command provides specific focus related help, illustrating various ways to use the focus
command. See the "Shell Object Messages" section for more.
help /cx
This command provides specific controller /cx related help, illustrating various commands associ-
ated 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 asso-
ciated with the enclosure /cx/ex. See the "Enclosure Services Commands" section for more.
help /cx/ex/slotx
This command provides specific slot /cx/ex/slotx related help, illustrating various ways to use
the /cx/ex/slotx command. See the "Enclosure Element Slot" section for more.
help /cx/ex/fanx
This command provides specific fan /cx/ex/fanx related help, illustrating various ways to use the
/cx/ex/fanx command. See the "Enclosure Element Fan" section for more.
help /cx/ex/tempx
This command provides specific temperature sensor /cx/ex/tempx related help, illustrating various
ways to use the /cx/ex/tempx command. See the "Enclosure Element Temperature Sensor" section for
more.
help /cx/ex/pwrsx
This command provides specific power supply /cx/ex/pwrsx related help, illustrating various ways
to use the /cx/ex/pwrsx command. See the "Enclosure Element Power Supply" section for more.
Command Logging
This feature logs various changeable controller commands from both CLI and 3DM2 into a file.
Setting the environment variable TW_CLI_LOG to ON or OFF will enable or disable various con-
troller commands logging into a log file called tw_mgmt.log.
Log environment:
When one of the following environment variable TW_CLI_LOG is set,
If Bash, then "export TW_CLI_LOG=ON"
If csh, then "setenv TW_CLI_LOG ON"
If Windows, then "set TW_CLI_LOG=ON"
Various changeable controller commands from both CLI and 3DM2 are logged into the log file
tw_mgmt.log.
Log location:
In Linux and FreeBSD, the log file is in the /var/log directory.
In Windows Vista, the log file is in \User\Common\CLI. In Window XP, the log file is in \Docu-
ments and Settings\All Users\Application Data\AMCC\CLI.
RETURN CODE
While informative messages are written to standard output, error messages are written to
standard error. On success, 0 is returned. On failure 1 is returned.
ERRATA
Meta-Character Warning:
If you wish to use CLI in single command mode (not interactive), make sure to avoid
collision with your command interpreter (OS shell) by escaping the meta-characters
(such as ?, <, >, @, &, *, etc) appropriately with single quote around them.
For example, given the
$ tw_cli /c0 ?
This is a case of single command usage where the user intends to get help on Con-
troller 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 easily parsed. The intent is to make CLI yet
another API (to approach it).
However to accommodate current automations around tw_cli and to ease the migration, the
old behavior can still be requested by setting TW_CLI_STYLE environment variable to OLD as
follows:
If Bash, then "export TW_CLI_STYLE=OLD"
If csh, then "setenv TW_CLI_STYLE OLD"
if Windows, then "set TW_CLI_STYLE=OLD"
This backward compatibility window, will be communicated by official AMCC/3ware represen-
tatives.
Initialization Process Control
On the 9K series of controllers, the rebuild scheduling controls both rebuild and initial-
ize processes if it is enabled. Currently, tw_cli(8) does not have any direct command to
pause or resume an initialization process. If such action is needed, use the rebuild
scheduling to handle it.
ENVIRONMENT VARIABLES
TW_CLI_STYLE setting this variable to OLD, will provide the old reporting style.
TW_CLI_INPUT_STYLE setting this variable to OLD, will disable focus feature in the inter-
active mode.
AUTHOR
Marian Choy
SEE ALSO
AMCC/3ware CLI User Guide
AMCC/3ware User Guide
AMCC/3ware Installation Guide
http://www.amcc.com
Version 2008-01-22 TW_CLI(8)
Generated by $Id: phpMan.php,v 4.49 2006/02/26 13:18:18 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2012-05-26 04:16 @38.107.179.238 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)