 |
|
- NAME
- SYNOPSIS
- DESCRIPTION
- Primary Command Syntax
- Shell Object Messages
- Controller Object Messages
- Logical Disk Object Messages
- Port Object Messages
- Phy Object Messages
- BBU Object Messages
- Enclosure Services Commands
- Enclosure Element Slot
- Enclosure Element Fan
- Enclosure Element Temperature Sensor
- Enclosure Element Power Supply
- Help Commands
- Command Logging
- RETURN CODE
- ERRATA
- AUTHOR
- SEE ALSO
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 Programming Interface) functionalities.
The CLI prompt indicates the current object in focus, expressed in URI (Universal Resource Identifier) syntax consisting of a hostname (//hostname), and an object path (/path/path/object) such as //elvis/c0/u0. User can set the focus to a particular object by focus URI.
CLI also supports comments. Command lines beginning with # denotes start of comment. This feature is mostly useful with batch processing via -f script flag.
CLI uses the following terminology:
Logical Units. Usually shortened to ``units'', these are block devices presented to the operating system. A logical unit can be a one-tier, two-tier, or three-tier arrangement. Spare and Single logical units are examples of one-tier units. RAID-1 and RAID-5 are examples of two-tier units and as such will have sub-units. RAID-10 and RAID-50 are examples of three-tier units and as such will have sub-sub-units.
Port. 3ware controller models up to the 9650SE series have one or many ports (typically 4, 8, 12, 16, or 24). Each port can be attached to a single disk drive. On a controller such as the 9650SE with a multilane serial port connector, one connector supports four ports. On 9690SA series controllers, connections are made with phys and vports (virtual ports).
Phy. Phys are tranceivers that transmit and receive the serial data stream that flows between the controller and the drives. The 9690SA controller have 8 phys. These ``controller phys'' are associated with virtual ports (vports) to establish up to 128 potential connections with the SAS or SATA drives. Each controller phy can be connected to a single drive, or can be connected through an expander to additional drives.
VPort. Connections from the 9690SA controller to drives are referred to as virtual ports, or vports. A vport indicates the ID of a drive, whether it is directly connected to the controller, or cascaded through one of more expanders. The vport, in essense, is a handle in the software to uniquely identify a drive. The port ID or vport ID allows a drive to be consistently identified, used and managed in a RAID unit. For dual-ported drives, although there are two connections to a drive, the drive is still identified with one vport handle. Note: With the controller summay via the command ``show'', the number of (V)Ports shown may contain two times (2X) the number of drives (suggesting the dual-ported drive type) even though the (V)Port column of the summary to the command ``/cx show'' contains only the number of vports corresponding to the number of drives. This is because the drive is identified with only one vport handle.
NOTE: For all practical purposes, hereafter port and vport are used interchangeably in reference to a drive (or disk). Therefore, unless otherwise specified, the mention of port implies vport as well. That is, while ``port'' is mentioned to denote a drive, it is implied that for the applicable controller series, the reference also applies to vport.
CLI supports a set of primary command syntax and a set of legacy command syntax that is the old or original command syntax. Note: The primary command syntax replaces that legacy command syntax and as such support for legacy commands will discontinue in the near future.
Please also note that some of the commands listed in this document are qualified with restrictions of controller type/model support. For example, ``9000 series'' or ``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 kernel device drivers should be loaded for the list to show all controllers. The intention is to provide a global view of the environment.
-
Typical output looks like:
-
//localhost> show
-
Ctl Model Ports Drives Units NotOpt RRate VRate BBU -------------------------------------------------------------------------------- c0 7500-12 12 8 3 1 2 - - c1 9506S-12 12 6 1 0 3 5 TESTING
-
The output indicates that Controller 0 is a 7500 model with 12 Ports, with 8 Drives detected (attached), total of 3 Units, with one unit in a NotOpt (Not Optimal) state, a RRate(Rebuild Rate) of 2, VRate(Verify Rate) of '-' (Not Applicable), BBU of '-' (Not Applicable). Not Optimal refers to any state except OK and VERIFYING. Other states include INITIALIZING, INIT-PAUSED, REBUILDING, REBUILD-PAUSED, DEGRADED, MIGRATING, MIGRATE-PAUSED, RECOVERY, INOPERABLE, and UNKNOWN.
-
For a system with an enclosure unit as an attached expander, and the appropriate controller (9690SA), a global view of the environment includes summary information about detected enclosures. As example:
-
//localhost> show
-
Ctl Model (V)Ports Drives Units NotOpt RRate VRate BBU --------------------------------------------------------------------------- c0 G133e/Astor 12 4 1 0 1 1 -
-
Encl Slots Drives Fans TSUnits PSUnits -------------------------------------------------- /c0/e0 4 2 1 1 1
-
The enclosure summary information shows the name of the enclosure, and the number of elements within each element type that is part of the system as identified during discovery.
- show ver
-
This command will show the CLI and API version.
-
For example:
-
//localhost> show ver CLI Version = 2.00.03.018 API Version = 2.01.00.004 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 system's name.
-
.. specifies one level up (the parent object).
-
/ specifies the root at the current focused host.
-
./obj specifies the next level of the object.
-
/c0/bbu specifies a relative path with respect to the current focused hostname.
-
For example:
-
//localhost> focus //elvis.amcc.com //elvis.amcc.com>
-
//elvis.amcc.com> focus /c0/u0 //elvis.amcc.com/c0/u0>
-
//elvis.amcc.com/c0/u0> focus .. //elvis.amcc.com/c0>
-
//elvis.amcc.com/c0> focus ./u0 //elvis.amcc.com/c0/u0>
-
//elvis.amcc.com/c0> focus / //elvis.amcc.com>
-
Note that focus is available as default. You can also set TW_CLI_INPUT_STYLE=OLD in the following to disable the feature.
-
If Bash, then "export TW_CLI_INPUT_STYLE=OLD" If csh, then "setenv TW_CLI_INPUT_STYLE OLD" If Windows, then "set TW_CLI_INPUT_STYLE=OLD"
Controller Object Messages
Controller Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller such as /c0.
- /cx show
-
This command shows summary information on the specified controller /cx. This report consists of two to three parts; a Unit summary listing all present units, a Port summary section listing of all present disks and their attached ports, and a BBU summary section listing if a BBU unit is installed on the controller.
-
The Unit summary section lists all present units specifying their Unit Number, Unit type (such RAID 5), the unit status (such as OK, VERIFYING, INITIALIZING, etc.), the %RCompl which reports percent completion, the %V/I/M which reports the percent completion of Verify, Initialize, or Migrating status of the unit, the stripe size, the usable capacity in Giga (or Tera) Bytes, the write cache 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, carvesize(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 controller /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 operation.
-
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 reasons. However, if there is no BBU available for the controller, a warning is sent to standard error. 2) The default drive queuing policy is enabled, unless it is specifically set to disable queuing by specifing noqpolicy. 3) The noqpolicy attribute is not applicable to the ``spare'' unit. Specifying the noqpolicy attribute returns an error.
-
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 supported 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 performance. Case of 15 disks could be grouped with group=3 or group=5. And case of 16 disks could be grouped with group=4 and group=8.
-
Note that the supported group number indicated depends on the number of ports on the controller. group=16 is the maximum and it is available on the 9690SA.
-
noscan attribute instructs CLI not to notify OS of creation of the new unit. By default CLI will inform the OS. One application of this feature is to avoid the OS from creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and creating a moving target.
-
nocache 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 created. For more details on this feature, refer to cx/ux set Commands section of this document. The following table illustrates the supported Model-Unit Type. This table only applies to setting this feature at unit creation time. Generally ignoreECC applies to redundant units.
-
Model | Raid0 | Raid1 | Raid5 | 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 characters which the OS command shell reserves such as '<', '>', '!', and '&', etc in the name string, the user has to use quote ``'' around the name string in order to bypass the command shell. User can change the name of the unit any time after the unit creation. This is a feature for 9000 or above series of controllers. Please refer to commands /cx/ux set name=sting for changing the name and /cx/ux show name for checking.
-
storsave=protect|balance|perform attribute allows user to set the storsave policy of the new unit. It is a 9KSX/SE only feature. Please refer to command /cx/ux set storsave=protect|balance|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 controller will update its list of ports (attached disks), and visits every DCB (Disk Configuration Block) in order to re-assemble its view and awareness of logical units. Any newly found
unit(s)ordrive(s)will be listed. noscan is used to not inform the OS of the unit discovery. Default is to inform the OS. -
Example:
-
//localhost> /c1 rescan
-
Rescanning controller /c1 for units and drives ...Done. Found following unit(s): [/c1/u3]. Found following drive(s): [/c1/p7, /c1/p8].
-
Note: Does not import non-JBOD on 7000/8000 models.
- /cx commit
-
This command instructs the controller to commit its dirty DCBs to persistent storage (ie disks). While controller is processing I/O requests against underlying disks, an in-transaction bit is set. If a failure (such as power failure) is experienced, subsequent read from the disks, will inform the controller that an un-clean shutdown took place. This command allows the end user to complete all pending I/Os on disks and clear the in-transaction bit.
-
Typical application of this feature is when an application is using a given unit in raw mode (such as databases) and user would like to shutdown the host (Including UPS post failure automations). This command can then expedite the process by instructing the controller to finish pending requests, clear DCB's in-transaction flag as we are going down.
-
Note that block devices (cooked devices) do not require this and clients of block devices (such as file systems) will send its own shutdown request to the devices.
-
This command only applies to Windows operating system.
- /cx flush
-
This command allows you to flush the write cache on all units associated with the /cx controller
- /cx update fw=filename_with_path [force]
-
This command allows the download of the specified firmware image to the corresponding controller. This command is for 9000 series controllers only.
-
fw=filename_with_path attribute allows the user to specify the firmware image file name along with its path. Please note that filename_with_path could not have spaces in the directory names of its path (as Windows would allow).
-
The new image specified by filename_with_path will be checked for compatibility with the current controller, current driver and current application versions. Subsequently a recommendation is given to the user followed by a prompt to continue. Once the user decides to proceed, the image will be downloaded to the controller. However, a reboot is required for the new image to take effect.
-
Example:
-
//localhost> /c2 update fw=/tmp/prom0006.img
-
Warning: 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 programs such as CLI and/or 3DMPlus. These events reflect warning, debugging and/or informative messages for end user.
-
Alarms generated on 7000/8000 models do not have dates, as such you'll see a '-' (read not-applicable) 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 background 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, regardless of what the unit-based policy is. If the policy is set to follow, then if a unit is degraded, firmware will follow whatever policy has been set for that unit.
- /cx set spinup=nn
-
This command allows you to set a controller based disk spin up policy. The value must be a positive integer between 1 to the number of disks/ports 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 carvesize volumes and a remaining volume. Each volume can be treated as an individual disk with its own file system. The default carvesize is 2 TB. This feature is useful for operating systems limited to 2 TB filesystems.
-
For example a 3 TB array would be configured into a 2 TB and a 1 TB volumes with default carvesize. For a 5 TB array, two 2 TB volumes would be created plus a 1 TB volume.
-
When autocarve policy is off, all the new unit creation or migration consists of one single volume.
-
Example:
-
//localhost> /c0 set autocarve=on Setting Auto-Carving Policy on /c0 to on ... Done.
- /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 autocarve above. See ``/cx set autocarve=on|off'' command above for details.
-
Example:
-
//localhost> /c0 set carvesize=2000 Setting Auto-Carving Size on /c0 to 2000 GB ... Done.
- /cx set autorebuild=on|off (9KSX/SE/SA only)
-
This command sets Auto-Rebuild policy to be on or off. If the policy is on, the firmware will choose drives in the following priority order for a 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 controller will try to detect all drives that are present and spin them up staggered in time, allowing the spread of power consumption on the power supply. Upon drive hot-plug, that is, not on power-on or reset, the default behavior of the system is automatic detection of the drives and immediate spin-up. This command would change the default behavior and set the controller to spin-up as the system at power-on.
-
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 functionality of a disk. This includes bad block detection and remapping, etc. The commands starts a media scan operation on the specified controller /cx.
- /cx stop mediascan
-
This command applies to 7000/8000 controllers. It provides media scrubbing for validating functionality of a disk. This includes bad block detection and remapping, etc. The commands stops a media scan operation on the specified controller /cx.
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 presented. If the Auto-Carving policy was on at the time the unit was created and the unit is over the carve size (default is 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: initializestatus, 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 Configuration Block) meta-data. As such the unit can later be imported back. noscan is used to not inform the OS of this change. Default is to inform the OS. The quiet option is for non-interactive mode.
-
Use caution when using this command. Units that are currently in use or mounted cannot be removed.
- /cx/ux del [noscan] [quiet]
-
This command allows you to delete a unit. Deleting a unit not only remove the specified unit from the controller's list of managed units, but also destroys the DCB (Disk Configuration Block) meta-data. Ports (or disks) associated with this unit will now be part of the free pool of managed disks. In another words, once the unit is deleted, all the data on the unit can not be recovered. noscan is used to not inform the OS of this change. Default is to inform the OS. The quiet option is for non-interactive mode.
-
Use caution when using this command. This is a destructive command and should be used with extreme care. Units that are currently in use or mounted should not be deleted.
- /cx/ux start rebuild disk=p [ignoreECC]
-
This command allows you to rebuild a DEGRADED unit by using the specified disk=p. Rebuild only applies to redundant arrays such as RAID-1, RAID-5, RAID-10 and RAID-50. During rebuild, bad sectors on the source disk will cause the rebuild to fail. You can allow for the operation to continue via ignoreECC. Rebuild process is a background task and will change the state of a unit to REBUILDING. Various show commands also show a percent completion as rebuilding progresses.
-
Note that the disk to be used to rebuild a unit, must be a SPARE or unconfigured disk.
- /cx/ux start verify
-
This command starts a background verification process on the specified unit /cx/ux. The following shows the supported matrix as a function of controller model and logical unit type. N/A (Not Applicable) refers to cases where the given logical unit type is not supported on that controller model.
-
Model | Raid0 | Raid1 | Raid5 | 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 feature is intended for model 7000 and 8000 only. Model 9000 has an on-board scheduler where rebuild operations can be scheduled to take place at specified start and stop times.
-
Rebuild resume function is provided to enable 7000/8000 users to achieve similar functionality with use of OS provided schedulers such as
cron(8)or,at(1)in Linux or user supplied programs. - /cx/ux stop verify
-
This command stops a background verification process on the specified unit /cx/ux. The following shows the supported matrix as a function of controller model and logical unit type. N/A (Not Applicable) refers to cases where the given logical unit type is not supported on that controller model.
-
Model | Raid0 | Raid1 | Raid5 | 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 controller /cx. Note that this command does not apply to spare unit types.
- /cx/ux set autoverify=on|off
-
This command allows you to turn on/off the autoverify operation on a specified unit /cx/ux. Once the autoverify=on, the RAID firmware will pick a time to start the verify process on the unit. If the allocated schedule windows is enabled, the verify process becomes active during the scheduled windows. Otherwise, the firmware will decide when the verify needs to be paused or restarted again before it completes.
-
You can use the show verify command to display the existing schedule windows. The autoverify operation is a continuous verify operation, which takes place within the existing schedule windows (displayed with /cx show verify) if the schedule is enabled. While the ``/cx show verify'' command allows you to see the time for the verify operation, this command allows you to enable or disable the autoverify operation on the specified unit. This feature only applies to 9000 models.
- /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 feature 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 reference with the unit. It is user's responsibility to give unique or redundant names on all units. This feature only applies to 9000 models.
- /cx/ux set qpolicy=on|off (9KSX/SE/SA only)
-
This command presents the queue policy of the firmware. If the queue policy is on, the firmware utilizes the drive queueing policy. Some drives do not support any queueing policy, this policy will have no effect on those drives.
-
For a spare unit, drive queuing is not meaningful or applicable. For example, when a spare undergo unit migration and becomes a true unit, it adopts the queue policy of the ``new'' unit. Thus, this commmand does not set the queue policy for the unit type spare.
-
Example:
-
//localhost> /c0/u5 set qpolicy = on
-
Setting Command Queuing Policy for unit /c0/u5 to [on] ... Done.
- /cx/ux set storsave=protect|balance|perform [quiet] (9KSX/SE/SA only)
-
This command sets the storsave policy of the firmware to be either protect, balance, or perform when the unit write cache is enabled.
-
This feature is available only within 9KSX/SE/SA controller family or above. There is a tradeoff among the available settings. The following description about the settings should help you to decide which one is suitable to you and your application. The protect mode is the default setting.
-
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 settings. When user sets the storsave to perform mode, it means:
-
1. ``Write Cache'' will not be disabled when the unit becomes ``DEGRADED'',
-
2. all data flushing from controller cache will be flushed to disk, and
-
3. incoming FUA (Force Unit Access) host request will be honored.
-
When storsave is set to perform, a warning about the data loss in the event of power failure is giving to user to confirm the option. If user want to skip the confirmation, [quiet] option can be used to by pass the warning.
-
balance -- provide more data protection than perform mode but less data 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 capacity), or change the stripe size.
-
The unit that results from the migration (destination unit) is subject to similar rules and policies that apply when creating a new unit. For example, a valid number of disks and parameters must be specified. The destination unit must use all source disks and potentially augment the number of disks in the disk=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 destination units, or single disks, but the source unit serial number will not be carried over to new unit. The new destination unit will have its own serial number.
-
type=RaidType consists of the destination unit RAID type as in raid0, raid1, raid5, raid10, raid50, raid6, or single.
-
For example ``type=raid5'' indicates the destination unit is RAID-5.
-
The following table illustrates valid migration paths:
-
Src/Dst | Raid0 | Raid1 | Raid5 | Raid10 | Raid50 | Single | JBOD | Spare | Raid6 | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid0 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid1 | Y | N | Y | Y | Y | Y | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid5 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid10 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid50 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Single | Y | Y | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ JBOD | N | N | N | N | N | N | N | N | N | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Spare | N | N | N | N | N | N | N | N | N | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+ Raid6 | Y | N | Y | Y | Y | N | N | N | Y | --------+-------+-------+-------+--------+--------+--------+------+-------+-------+
-
Note: You can only migrate a unit to a RAID level that has the same or larger capacity as the exisiting one. A four-drive RAID-5 unit can migrate to a four-drive RAID-0, but a four-drive RAID-0 unit cannot migrate to a four-drive RAID-5, without adding another drive, due to the need for additional storage capacity for parity bits.
-
disk=p:-p consists of a list of ports or vports (disks) to be used in addition to the source disks in the construction of the destination unit. One or more ports can be specified. Multiple ports can be specified using ``:'' or ``-'' as port index separators. A dash indicates a range and can be mixed with ``:''. For example disk=0:1:2-5:9:12 indicates port 0, 1, 2 thru 5 (inclusive), 9 and 12.
-
group=3|4|5|6|7|8|9|10|11|12|13|14|15|16 is only applicable to type=raid50 which consists of a number of disks per group. Recall that a RAID-50 is a multi-tier array. At the most bottom layer, N number of disks per group are used to form the RAID-5 layer. These RAID-5 arrays are then integrated into a RAID-0. This option allows you to specify the number of disks in the RAID-5 level. Valid values are 3, 4, 5 and 6. For example group=3 indicates 3 disks of RAID-5 at the bottom layer of RAID-50.
-
Note: You can have a maximum of 4 subunits in a RAID-50 unit.
-
Note that a sufficient number of disks are required for a given pattern or disk group. For example, given 6 disks, specifying 3 will create two RAID-5. However given 12 disks, specifying 3 will create four RAID-5 under the RAID-0 level. Given 6 disks and grouping of 6 is not allowed, as you'll basically be creating a RAID-5.
-
The default disk group varies based on number of disks. For 6 & 9 disks, default is group=3. For 8 disks, default is group=4. For 10 or 15 disks, default is group=5. For 12 or 16 disks, default is group=4. For 14 disks, default is group=7. Case of 12 disks could be grouped with group=3, group=4, or group=6. Group=4 was set by default as it provides best net capacity and performance. Case of 15 disks could be grouped with group=3 or group=5. And case of 16 disks could be grouped with group=4 and group=8.
-
Note that RAID-10 always has group=2, so an attribute specifying its group is not necessary.
-
Stripe consists of the logical unit stripe size to be used. The following table illustrates the supported and applicable stripes on the respective unit types and controller models. Stripe size units are in KB (kilobytes).
-
Model | Raid0 | Raid1 | Raid5 | 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 creating block special devices such as /dev/sdb and /dev/sdc as some implementations might create naming fragmentation and a moving target.
-
nocache instructs CLI to disable the write cache on the migrated unit. Enabling write cache increases performance, but at the cost of potential data loss in the event of sudden power loss (unless a BBU or UPS is installed). By default the cache is enabled. Unless there is a BBU or UPS installed, to avoid the possibility of data loss in the event of sudden power loss, it is recommended that nocache be specified.
-
autoverify enables the autoverify attribute on the unit to be migrated. For more details on this feature, refer to cx/ux set autoverify section of this document.
-
Migration Process. In all cases of migration, the background migration process must be completed before the newly sized unit is available for use. You can continue using the original unit during this time. Once the migration is finished, a reboot will be required if you are booted from the unit. For secondary storage, depending on your operating system, you may need to first unmount the unit, then use CLI to 'remove' and 'rescan' the unit so that the operating system can see the new capacity, and then remount the unit.
-
You may also need to resize the file system or add a new partition. For instructions, consult the documentation for your operating system.
-
Note: It is important that you allow migration to complete before adding drives to the unit or move it to another controller. Making any physical changes to the unit during migration may cause the migration to stop, and can jeopardize the safety of your data.
-
Examples. The two examples which follow show the usage of this command for splitting a mirror and for capacity expansion, respectively. Following those are sample outputs of the migrate function. After which example outputs showing the special case are presented.
-
Example of split mirror:
-
//localhost> /c1/u3 migrate type=single Sending migration message to /c1/u3 ... Done.
-
The source unit u3 is a TWINSTOR or RAID-1, using the migrate command splits u3 to u3 and ux, each with the RAID type of Single.
-
Example of capacity expansion:
-
//localhost> /c0/u3 migrate type=raid10 disk=10-11 stripe=16 Sending migration message to /c0/u3 ... Done.
-
The source unit is u3 and the destination unit is RAID-10 with disks 10 and 11 in addition to the disks in the existing unit u3.
-
The following is an example of how migrating units are displayed. In this example, the set of reports indicate that /c0/u3 is a migrating unit with 39% completion. The ``/c0/u3 show'' command shows that the source unit is su3 and is of type RAID-1, and the destination unit du3 is of type RAID-10.
-
3ware CLI> /c0 show
-
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 64K 596.004 ON OFF u2 SPARE OK - - - 149.042 - OFF u3 Migrator MIGRATING - 39 - 149.001 ON OFF
-
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 WD-WCANM1771318 p1 OK u0 149.05 GB 312581808 WD-WCANM1757592 p2 OK u0 149.05 GB 312581808 WD-WCANM1782201 p3 OK u0 149.05 GB 312581808 WD-WCANM1753998 p4 OK u2 149.05 GB 312581808 WD-WCANM1766952 p5 OK u3 149.05 GB 312581808 WD-WCANM1882472 p6 OK u0 149.05 GB 312581808 WD-WCANM1883862 p7 OK u3 149.05 GB 312581808 WD-WCANM1778008 p8 OK - 149.05 GB 312581808 WD-WCANM1770998 p9 NOT-PRESENT - - - - p10 OK u3 149.05 GB 312581808 WD-WCANM1869003 p11 OK u3 149.05 GB 312581808 WD-WCANM1762464
-
3ware CLI> /c0/u3 show
-
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u3 Migrator MIGRATING - 39 - - -
-
su3 RAID-1 OK - - - - 149.001 su3-0 DISK OK - - p5 - 149.001 su3-1 DISK OK - - p7 - 149.001 su3/v0 Volume - - - - - 149.001
-
du3 RAID-10 OK - - - 16K 298.002 du3-0 RAID-1 OK - - - - - du3-0-0 DISK OK - - p5 - 149.001 du3-0-1 DISK OK - - p7 - 149.001 du3-1 RAID-1 OK - - - - - du3-1-0 DISK OK - - p10 - 149.001 du3-1-1 DISK OK - - p11 - 149.001 du3/v0 Volume - - - - - 149.001
-
Please note that the migration path of raidtype Single to RAID-1 is a special case. Since the single unit would become a mirrored array, technically this is not a migration. As a result this command shows a different status than other migration paths. In addition, the status of the newly specified disk would show DEGRADED until the ``migration'' is complete.
-
For example, below is a system with two migrating units, /c0/u0 and /c0/u1. u0 is migrating from a RAID-10 to a RAID-0 array, while u1 is migrating from Single to a RAID-1, initiated by the following commands:
-
/c0/u0 migrate type=raid0
-
and
-
/c0/u1 migrate type=raid1 disk=5
-
Note the difference in 'UnitType' and 'Status' of u0 and u1, even though they are both migrating units.
-
3ware CLI> /c0 show
-
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 Migrator MIGRATING - 26 - 298.002 ON OFF u1 RAID-1 REBUILD-PAUSED 0 - - 372.519 OFF OFF
-
Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 149.05 GB 312581808 WD-WCANM1883862 p1 OK u0 149.05 GB 312581808 WD-WCANM1754124 p2 OK u0 372.61 GB 781422768 WD-WMAMY1661939 p3 OK u0 372.61 GB 781422768 WD-WMAMY1579179 p4 OK u1 372.61 GB 781422768 WD-WMAMY1662720 p5 DEGRADED u1 372.61 GB 781422768 WD-WMAMY1576310 p6 NOT-PRESENT - - - - p7 NOT-PRESENT - - - -
-
3ware CLI> /c0/u3 show
-
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u0 Migrator MIGRATING - 26 - - -
-
su0 RAID-10 OK - - - 64K 298.002 su0-0 RAID-1 OK - - - - - su0-0-0 DISK OK - - p0 - 149.001 su0-0-1 DISK OK - - p1 - 149.001 su0-1 RAID-1 OK - - - - - su0-1-0 DISK OK - - p2 - 149.001 su0-1-1 DISK OK - - p3 - 149.001 su0/v0 Volume - - - - - 298.002
-
du0 RAID-0 OK - - - 64K 596.004 du0-0 DISK OK - - p3 - 149.001 du0-1 DISK OK - - p2 - 149.001 du0-2 DISK OK - - p1 - 149.001 du0-3 DISK OK - - p0 - 149.001 du0/v0 Volume - - - - - N/A
-
3ware CLI> /c0/u1 show
-
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB) ------------------------------------------------------------------------ u1 RAID-1 REBUILD-PAUSED 0 - - - 372.519 u1-0 DISK OK - - p4 - 372.519 u1-1 DISK DEGRADED - - p5 - 372.519 u1/v0 Volume - - - - - 372.519
Port Object Messages
Port Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a disk which attaches to a port or vport such as /c0/p0. Note: All references of port also applies to vport for the commands in this section.
- /cx/px show
-
This command shows summary information on the specified disk attached to port /cx/px. 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 status, 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-introduce) the port via rescan. noscan is used to not inform the OS of this change. Default is to inform the OS. The quiet option is for non-interactive mode.
-
Use caution when using this command. Drives, which are part of a redundant array, can be removed, but the array will be degraded. Non-redundant drives, which are part of a unit, can not be removed.
- /cx/px set identify=on|off (9550SX, 9590SE and 9690SA only)
-
This command sets the LED status of the port. If the identify is set to on, the firmware activates the setting of the corresponding LED of the port. If the setting of the configuration for LED is blinking for identify=on, this will blink the LED of the port.
-
Note: Enclosure services hardware is also required.
-
Example:
-
//localhost> /c0/p5 set identify=on
-
Setting Port Identify on /c0/p5 to [on] ... Done.
Phy Object Messages
Phy Object Messages are commands (a.k.a. methods/messages) that are sent to an instance of a controller phy such as /c0/phy0.
- /cx/phyx show (9690SA only)
-
This command presents a summary report on the specified phy. The 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 estimated to last for 72 hours from the last tested date. The BBU unit is currently testing the battery. Both voltage and temperature are normal. 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:
- /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 operating range and need to be concerned.
- /cx/bbu show temp
-
This command shows the temperature status of the battery. The status can be OK, HIGH, LOW, TOO-HIGH, and TOO-LOW. The HIGH and LOW are in warning range. TOO-HIGH and TOO-LOW are out of the operating range and need to be concerned.
- /cx/bbu show cap
-
This command shows the battery capacity in hours.
- /cx/bbu show serial
-
This command shows the BBU serial number.
- /cx/bbu show fw
-
This command shows the BBU board firmware version number.
- /cx/bbu show pcb
-
This command shows the PCB revision number on the BBU unit.
- /cx/bbu show bootloader
-
This command shows the BBU's Boot Loader version.
- /cx/bbu show all
-
This command shows the current settings of all above attributes on the BBU board.
-
For example:
-
//localhost> /c1/bbu show all
-
/c1/bbu Firmware Version = BBU: 1.04.00.007 /c1/bbu Serial Number = Engineering Sample. /c1/bbu Online State = On /c1/bbu BBU Ready = Yes /c1/bbu BBU Status = OK /c1/bbu Battery Voltage = OK /c1/bbu Battery Temperature = OK /c1/bbu Estimated Backup Capacity = 241 Hours /c1/bbu Last Capacity Test = 22-Jun-2004 /c1/bbu Battery Intallation Date = 20-Jun-2004 /c1/bbu Bootloader Version = BBU 0.02.00.002 /c1/bbu PCB Revision = 65
-
//localhost>
- /cx/bbu test [quiet]
-
This command starts the battery capacity test. The test may take up to 24 hours to complete. During the test, the BBU is not capable of backup 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 detection is disabled. The quiet option is for non-interactive mode.
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.
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, temperature 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 enclosure.
-
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 specified 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 identified.
-
Example:
-
//localhost> /c0/e0/slot1 show
-
Slot Status (V)Port Identify ---------------------------------------------------- slot1 OK /c0/p1 On
- /cx/ex/slotx show identify
-
This command shows the identify status of the specified enclosure slot.
-
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 elements in the enclosure unit.
- /cx/ex/tempx show
-
This command shows information about the specified temperature sensor element. The possible status values are OK, OVER-WARNING, OVER-FAIL, UNDER-WARNING, UNDER-FAIL, where OVER denotes over-temperature and UNDER denotes under-temperature.
-
Example:
-
//localhost> /c0/e0/temp0 show
-
TempSensor Status Temperature Identify -------------------------------------------------------- temp0 OK 42C(107F) Off
- /cx/ex/tempx show identify
-
This command shows the identify status of the specified temperature sensor element of the specified 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 command. It provides reports on Controllers, Units and Drives. See the Shell Object Messages section for more on show.
- help flush
-
This command provides specific flush related help, illustrating various ways to use the flush command. See the Shell Object Messages section for more.
- help rescan
-
This command provides specific rescan related help, illustrating various ways to use the rescan command. See the Shell Object Messages section for more.
- help update
-
This command provides specific update related help. See the Shell Object Messages section for more.
- help commit
-
This command provides specific commit related help, illustrating various ways to use the commit command. See the Shell Object Messages section for more.
- help focus
-
This command provides specific focus related help, illustrating various ways to use the focus command. See the Shell Object Messages section for more.
- help /cx
-
This command provides specific controller /cx related help, illustrating various commands associated with the controller /cx. See the Controller Object Messages section for more.
- help /cx/ux
-
This command provides specific unit /cx/ux related help, illustrating various commands to use on a unit /cx/ux. See the Controller Object Messages section for more.
- help /cx/px
-
This command provides specific /cx/px related help, illustrating various ways to use the /cx/px command. See the Port Object Messages section for more.
- help /cx/phyx
-
This command provides specific /cx/phyx related help, illustrating various ways to use the /cx/phyx command. See the Phy Object Messages section for more.
- help /cx/bbu
-
This command provides specific /cx/bbu related help, illustrating various ways to use the /cx/bbu command. See the BBU Object Messages section for more.
- help /cx/ex
-
This command provides specific enclosure /cx/ex related help, illustrating various commands associated with the enclosure /cx/ex. See the Enclosure Services Commands section for more.
- help /cx/ex/slotx
-
This command provides specific slot /cx/ex/slotx related help, illustrating various ways to use the /cx/ex/slotx command. See the Enclosure Element Slot section for more.
- help /cx/ex/fanx
-
This command provides specific fan /cx/ex/fanx related help, illustrating various ways to use the /cx/ex/fanx command. See the Enclosure Element Fan section for more.
- help /cx/ex/tempx
-
This command provides specific temperature sensor /cx/ex/tempx related help, illustrating various ways to use the /cx/ex/tempx command. See the Enclosure Element Temperature Sensor section for more.
- help /cx/ex/pwrsx
-
This command provides specific power supply /cx/ex/pwrsx related help, illustrating various ways to use the /cx/ex/pwrsx command. See the Enclosure Element Power Supply section for more.
Command Logging
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 controller 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 \Documents 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 Controller
related commands. While this is a valid CLI command, but since the arguments to CLI
are first processed by the shell, then some shells like csh(1) will interpret the '?' as
a meta-character to be used toward file completion and if no file is found with a single
character, then shell will complain before the arguments are even passed down to CLI.
One solutions of this problem can be :
$ tw_cli help /cx
or
$ tw_cli '/c0 ?'
Note: Some of the OS shell does not have this problem such as bash.
Reporting Style
tw_cli(8) reporting has changed (hopefully for better). The intent has been to provide a consistent tabular reporting so that relevant and important information (such as B<info>) are made available as fast as possible. For example, firmware, PCB, PCHIP and similar information have been removed from the info summary report, as this type of information is not frequently needed.
The new style also accommodates automation much better by providing consistent columns with or without values so that it could be easily parsed. The intent is to make CLI yet another API (to approach it).
However to accommodate current automations around tw_cli and to ease the migration, the old behavior can still be requested by setting TW_CLI_STYLE environment variable to OLD as follows:
If Bash, then "export TW_CLI_STYLE=OLD" If csh, then "setenv TW_CLI_STYLE OLD" if Windows, then "set TW_CLI_STYLE=OLD"
This backward compatibility window, will be communicated by official AMCC/3ware representatives.
Initialization Process Control
On the 9K series of controllers, the rebuild scheduling controls both rebuild and
initialize processes if it is enabled. Currently, tw_cli(8)
does not have any direct command to pause or resume an initialization process.
If such action is needed, use the rebuild scheduling to handle it.
=head1 ENVIRONMENT VARIABLES
TW_CLI_STYLE setting this variable to OLD, will provide the old reporting style. TW_CLI_INPUT_STYLE setting this variable to OLD, will disable focus feature in the interactive mode.
AUTHOR
Marian Choy
SEE ALSO
AMCC/3ware CLI User Guide AMCC/3ware User Guide AMCC/3ware Installation Guide http://www.amcc.com
CycleSeeder
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback