Next
Previous
Contents
In addition to the text based GUI the RAID configuration may also be manipulated
from the husky prompt ( the : raid; prompt) of the onboard controller. This
section describes commands that a user can input interactively or via a script
file to the K9 kernel. Since K9 is an ANSI C Application Programming Interface
(API) a shell is needed to interpret user input and form output. Only one shell
is currently available and it is called husky. The K9 kernel is modelled on
the Plan 9 operating system whose design is discussed in several papers from
AT&T (See the "Further Reading" section for more information).
K9 is a kernel targeted at embedded controllers of small to medium complexity
(e.g. ISDN-ethernet bridges, RAID controllers, etc). It supports multiple lightweight
processes (i.e. without memory management) on a single CPU with a non-pre-emptive
scheduler. Device driver architecture is based on Plan 9 (and Unix SVR4) STREAMS.
Concurrency control mechanisms include semaphores and signals. The husky shell
is modelled on a scaled down Unix Bourne shell.
Using the built-in commands the user can write new scripts thus extending
the functionality of the 5070. The commands (adapted from the 5070 man pages)
are extensive and are described below.
- SYNOPSIS: autoboot
- DESCRIPTION: autoboot is a husky script which is typically executed when
a RaidRunner boots. The following steps are taken -
- Start all configured scsi monitor daemons (smon).
- Test to see if the total cache required by all the raid sets that are to
boot is not more than 90% of available memory.
- Start all the scsi target daemons (stargd) and set each daemon's mode
to "spinning-up" which enables it to respond to all non medium
access commands from the host. This is done to allow hosts to gain knowledge
about the RaidRunner's scsi targets as quickly as possible.
- Bind into the root (ram) filesystem all unused spare backend devices.
- Build all raid sets.
- If battery backed-up ram is present, check for any saved writes and
restore them into the just built raid sets.
- Finally, set the state of all scsi target daemons to "spun-up"
enabling hosts to fully access the raid set's behind them.
- SYNOPSIS: autofault raidset
- DESCRIPTION: autofault is a husky script which is typically executed
by a raid file system upon the failure of a backend of that raid set when that
raid file system cannot use spare backends or has been configured not to use
spare backends. After parsing it's arguments (command and environment) autofault
issues a rconf command to mark a given backend as faulty.
- OPTIONS:
- raidset: The bind point of the raid set whose backend failed.
- $DRIVE_NUMBER: The index of the backend that failed. The first backend
in a raid set is 0. This option is passed as an environment variable.
- $BLOCK_SIZE: The raid set's io block size in bytes. (Ignored).
This option is passed as an environment variable.
- $QUEUE_LENGTH: The raid set's queue length. (Ignored). This option
is passed as an environment variable.
- SEE ALSO: rconf
- SYNOPSIS: autorepair raidset size
- DESCRIPTION: autorepair is a husky script which is typically executed
by either a raid type 1, 3 or 5 file system upon the failure of a backend of
that raid set.
After parsing it's arguments (command and environment) autorepair gets
a spare device from the RaidRunner's spares spool. It then engages it
in write-only mode and reads the complete raid device which reconstructs the
data on the spare. The read is from the raid file system repair entrypoint.
Reading from this entrypoint causes a read of a block immediately
followed by a write of that block. The read/write sequence is atomic (i.e is
not interruptible). Once the reconstruction has completed, a check is made
to ensure the spare did not fail during reconstruction and if not, the access
mode of the spare device is set to the access mode of the raid set. The process
that reads the repair entrypoint is rebuild.
This device reconstruction will take anywhere from 10 minutes to one and
a half hours depending on both the size and speed of the backends and the amount
of activity the host is generating.
During device reconstruction, pairs of numbers will be printed indicating
each 10% of data reconstructed. The pairs of numbers are separated
by a slash character, the first number being the number of blocks reconstructed
so far and the second being the number number of blocks to be reconstructed.
Further status about the rebuild can be gained from running rebuild.
When the spare is allocated both the number of spares currently used on
the backend and the spare device name is printed. The number of spares on a
backend is referred to the depth of spares on the backend. Thus prior
to re-engaging the spare after a reconstruction a check can be made to see
if the depth is the same. If it is not, then the spare reconstruction failed
and reconstruction using another spare is underway (or no spares are available),
and hence we don't re-engage the drive.
- OPTIONS:
- raidset: The bind point of the raid set whose backend failed.
- size : The size of the raid set in 512 byte blocks.
- $DRIVE_NUMBER: The index of the backend that failed. The first
backend in a raid set is 0. This option is passed as an environment variable.
- $BLOCK_SIZE: The raid set's io block size in bytes. This option
is passed as an environment variable.
- $QUEUE_LENGTH: The raid set's queue length. This option is passed
as an environment variable.
- SEE ALSO: rconf, rebuild
- SYNOPSIS: bind [-k] new old
- DESCRIPTION: Bind replaces the existing old file (or directory) with the
new file (or directory). If the"-k" switch is given then new must
be a kernel recognized device (file system). Section 7k of the manual pages
documents the devices (sometimes called file systems) that can be bound using
the "-k" switch.
- SYNOPSIS: buzzer or buzzer on|off|mute
- DESCRIPTION: Buzzer will either print the state of the buzzer, turn on
or off the buzzer or mute it. If no arguments are given then the state of
the buzzer is printed, that is on or off will be printed if the buzzer is currently
on or off respectively. If the buzzer has been muted, then you will be informed
of this. If the buzzer has not been used since the RaidRunner has booted then
the special state, unused, is printed. If the argument on is given the buzzer
is turned on, if off, the buzzer is turned off. If the argument mute is given
then the muted state of the buzzer is changed.
- SEE ALSO: warble, sos
- SYNOPSIS: cache [-D moniker] [-I moniker] [-F]
[-g moniker first|last] lastoffset
- DESCRIPTION: cache will print (to standard output) information about
the given cache range, delete a given cache range, flush the cache or return
the last offset of all cache ranges.
- OPTIONS
- -F: Flush all cache buffers to their backends (typically raid sets).
- -D moniker: Delete the cache range with moniker (name) moniker.
- -I moniker: Invalidate the cache for the given cache range (moniker). This
is only useful for debugging or elaborate benchmarks.
- g moniker first|last: Print either the first or last block number of a
cache range with moniker (name) moniker.
- lastoffset: Print the last offset of all cache ranges. The last offset
is the last block number of all cache ranges.
- SYNOPSIS: cachedump
- DESCRIPTION: cachedump causes all unwritten data in the RaidRunner's cache
to be written out to the battery backed-up ram. No data will be written to
battery backed-up ram if there is currently valid data already stored there.
This command is typically executed when there is something wrong with the data
(or it's organization) in battery backed-up ram and you need to re-initialize
it. cachedump will always return a NULL status.
- SEE ALSO: showbat, cacherestore
- SYNOPSIS: cacherestore
- DESCRIPTION: cacherestore will check the RaidRunner's battery backed-up
ram for any data it has stored as a result of a power failure. It will copy
any data directly into the cache. This command is typically executed automatically
at boot time and prior to the RaidRunner making it's data available to a
host. Having successfully copied any data from battery backed-up ram into the
cache, it flushes the cache and then re-initializes battery backed-up ram to
indicate it holds no data. cacherestore will return a NULL status on success
or 1 if an error occurred during the loading (with a message written to standard
error).
- SEE ALSO: showbat
- SYNOPSIS: cat [ file... ]
- DESCRIPTION: cat writes the contents of each given file, or standard input
if none are given or when a file named `-' is given, to standard output. If
the nominated file is a directory then the filenames contained in that directory
are sent to standard out (one per line). More information on a file (e.g. its
size) can be obtained by using stat. The script file ls uses cat and stat to
produce directory listings.
- SEE ALSO echo, ls, stat
- SYNOPSIS: cmp [-b blockSize] [-c count] [-e]
[-x] file1 file2
- DESCRIPTION: cmp compares the contents of the 2 named files. If file1 is
"-" then standard input is used for that file. If the files are
the same length and contain the same val ues then nothing is written to standard
output and the exit status NIL (i.e. true) is set. Where the 2 files dif fer,
the first bytes that differ and the position are out put to standard out and
the exit status is set to "differ" (i.e. false). The position is
given by a block number (origin 0) followed by a byte offset within that block
(origin 0). The optional "-b" switch allows the blockSize of each
read operation to be set. The default blockSize is 512 (bytes). For big compares
involving disks a relatively large blockSize may be useful (e.g. 64k). See
suffix for allowable suffixes. The optional "-c" switch allows
the count of blocks read to fixed. A value of 0 for count is interpreted as
read to the end of file (EOF). To compare the first 64 Megabytes of 2 files
the switches "-b 64k -c 1k" could be used. See suffix for allowable
suffixes. The optional "-e" switch instructs ccmmpp to output to
stan dard out (usually overwriting the same line) the count of blocks compared,
each time a multiple of 100 is reached. The final block count is also output.
The optional "-x" switch instructs ccmmpp to continue after a comparison
error (but not a file error) and keep a count of blocks in error. If any errors
are detected only the last one will be output when the command exits. If the
"-e" switch is also given then the current count of blocks in error
is output to the right of the multiple of 100 blocks compared. This command
is designed to compare very large files. Two buffers of blockSize are allocated
dynamically so their size is bounded by the amount of memory (i.e. RAM in the
target) available at the time of command execution. The count could be up to
2G. The number of bytes compared is the product of blockSize and count (i.e.
big enough).
- SEE ALSO: suffix
- SYNOPSIS: bind -k cons bind_point
- DESCRIPTION: cons allows an interpreter (e.g. Husky) to route console
input and output to an appropriate device. That console input and output is
available at bind_point in the K9 namespace. The special file cons should always
be available.
- EXAMPLES: Husky does the following in its initialisation:
bind -k cons /dev/cons
On a Unix system this is equivalent to:
bind -k unixfd /dev/cons
On a DOS system this is equivalent to:
bind -k doscon /dev/cons
On target hardware using a SCN2681 chip this is equivalent to:
bind -k scn2681 /dev/cons
SEE ALSO: unixfd, doscon, scn2681
- SYNOPSIS: dd [if=file] [of=file] [ibs=bytes]
[obs=bytes] [bs=bytes] [skip=blocks] [seek=blocks]
[count=blocks] [flags=verbose]
- DESCRIPTION: dd copies a file (from the standard input to the standard
output, by default) with a user-selectable blocksize.
- OPTIONS
- if=file Read from file instead of the standard input.
- of=file, Write to file instead of the standard output.
- ibs=bytes, Read given number of bytes at a time.
- obs=bytes, Write given number of bytes at a time.
- bs=bytes, Read and write given number of bytes at a time. Override ibs
and obs.
- skip=blocks, Skip ibs-sized blocks at start of input.
- seek=blocks, By-pass obs-sized blocks at start of output.
- count=blocks, Copy only ibs-sized input blocks.
- flags=verbose, Print (to standard output) the number of blocks copied every
ten percent of the copy. The output is of the form X/T where X is the number
of blocks copied so far and T is the total number of blocks to copy. This option
can only be used if both the count= and of= options are also given.
The decimal numbers given to "ibs", "obs", "bs",
"skip", "seek" and "count" must not be
negative. These numbers can optionally have a suffix (see suffix). dd outputs
to standard out in all cases. A successful copy of 8 (full) blocks would cause
the following output:
8+0 records in
8+0 records out
The number after the "+" is the number of fractional blocks
(i.e. blocks that are less than the block size) involved. This number will
usually be zero (and is otherwise when physical media with alignment requirements
is involved).
A write failure outputting the last block on the previous example would
cause the following output:
Write failed
8+0 records in
7+0 records out
SEE ALSO: suffix
- SYNOPSIS: devscmp filename size
- DESCRIPTION: devscmp will find the size of the given file and compare it's
size in 512-byte blocks to the given size (to be in 512-byte blocks). If the
size of the file is less than the given value, then -1 is printed, if equal
to then 0 is printed, and if the size of the given file is greater than the
given size then 1 is printed. This routine is used in internal scripts to ensure
that backends of raid sets are of an appropriate size.
- SYNOPSIS
- dformat -p c.s.l -R bnum
- dformat -p c.s.l -pdA|-pdP|-pdG
- dformat -p c.s.l -S [-v] [-B firstbn]
- dformat -p c.s.l -F
- dformat -p c.s.l -D file
- DESCRIPTION: In it's first form dformat will either reassign a block on
a nominated disk drive. via the SCSI-2 REASSIGN BLOCKS command. The second
form will allow you to print out the current manufacturers defect list (-pdP),
the grown defect list (-pdG) or both defect lists (-pdA). Each printed list
is sorted with one defect per line in Physical Sector Format - Cylinder Number,
Head Number and Defect Sector Number. The third form causes the drive to be
scanned in a destructive write/read/compare manner. If a read or write or
data comparison error occurs then an attempt is made to identify the bad sector(s).
Typically the drive is scanned from block 0 to the last block on the drive.
You can optionally give an alternative starting block number. The fourth form
causes a low level format on the specified device. The fifth option allows
you to download a device's microcode into the device.
- OPTIONS:
- -R bnum: Specify a logical block number to reassign to the drive's grown
defect list.
- -pdA: Print both the manufacturer's and grown defect list.
- \ -pdP: Print the manufacturer's defect list.
- -pdG: Print the grown defect list.
- -S: Perform a destructive scan of the disk reporting I/O errors.
- -B firstbn: Specify the first logical block number to start a scan from.
- -v: Turn on verbose mode - which prints the current block number being
scanned.
- -F: Issue a low-level SCSI format command to the given device. This will
take some time.
- -D file: Download into the specified device, the given file. The download
is effected by a single SCSI Write-Buffer command in save microcode mode. This
allows users to update a device's microcode. Use this command carefully
as you could destroy the device by loading an incorrect file.
- -p c.s.l: Identify the disk device by specifying it's channel, SCSI ID
(rank) and SCSI LUN provided in the format "c.s.l"
- SEE ALSO: Product manual for disk drives used in your RAID.
- SYNOPSIS: diags disk -C count -L length -M io-mode -T io-type -D device
- DESCRIPTION: diags is a husky script which is used to run the randio diagnostic
on a given device. When randio is executed, it is executed in verbose mode.
- OPTIONS:
- disk: This is the device type of diagnostic we are to run.
- -C count: Specify the number of times to execute the diagnostic.
- -L length: Specify the "length" of the diagnostic to execute.
This can be either short, medium or long and specified with the letter's s,
m or l respectively. In the case of a disk, a short test will the first 10%
of the device, a medium the first 50% and long the whole (100%)
of the disk.
- -M io-mode: Specify a destructive (read-write) or non-destructive (read-only)
test. Use either read-write or read-only.
- -T io-type: Specify a type of io - either sequential or random.
- -D device: Specify the device to test.
- SEE ALSO: randio, scsihdfs
- SYNOPSIS:
- dpart -a|d|l|m -D file [-N name] [-F firstblock] [-L
lastblock]
- dpart -a -D file -N name -F firstblock -L lastblock
- dpart -d -D file -N name
- dpart -l -D file
- dpart -m -D file -N name -F firstblock -L lastblock
- DESCRIPTION: Each scsihd device (typically a SCSI disk drive) can be
divided up into eight logical partitions. By default when a scsihd device is
bound into the RaidRunner's file system, it has four partitions, the whole
device (raw), typically named bindpoint/raw, the partition file (bindpoint/partition),
the RaidRunner backup configuration file (bindpoint/rconfig), and the "data"
portion of the disk (bind- point/data) which represents the whole device less
the backup configuration area and partition file. For more information, see
scsihdfs. If other partitions are added, then they will appear as bindpoint/partitionname.
dpart allows you to edit or list the partition table on a scsihd device (typically
a disk).
- OPTIONS:
- -a: Add a partition. When adding a partition, you need to specify the partition
name (-N) and the partition range from the first block (-F) to the last
block (-L).
- -d: Delete a named (-N) partition.
- -l: List all partitions.
- -m: Modify an existing partition. You will need to specify the partition
name (-N) and BOTH it's first (-F) and last (-L) blocknumbers even if you are
just modifying the last block number.
- -D file: Specify the partition file to be edited. Typically, this is the
bindpoint/partition file.
- -N name: Specify the partition name.
- -F firstblock: Specify the first block number of the partition.
- -L lastblock: Specify the last block number of the partition.
- SEE ALSO: scsihd
- SYNOPSIS: bind -k dup bind_point
- DESCRIPTION: The dup device makes a one level directory with an entry in
that directory for every open file descriptor of the invoking K9 process. These
directory "entries" are the numbers. Thus a typical process (script)
binding a dup device would at least make these files in the namespace: "bind_point/0",
"bind_point/1" and "bind_point/2". These would correspond
to its open standard in, standard out and standard error file descriptors.
A dup device allows other K9 processes to access the open file descriptors
of the invoking process. To do this the other processes simply "open"
the required dup device directory entry whose name (a number) corresponds
to the required file descriptor.
- SYNOPSIS: echo [string ...]
- DESCRIPTION: echo writes each given string to the standard output, with
a space between them and a newline after the last one. Note that all the string
arguments are written in a single write kernel call. The following backslash-escaped
characters in the strings are converted as follows:
\b backspace
\c suppress trailing newline
\f form feed
\n new line
\r carriage return
\t horizontal tab
\v vertical tab
\\ backslash
\nnn the character whose ASCII code is nnn (octal)
- SYNOPSIS: bind -k env bind_point
- DESCRIPTION: env file system associates a one level directory with the
bind_point in the K9 namespace. Each file name in that directory is the name
of the environment variable while the contents of the file is that variable's
current value. Conceptually each process sees their own copy of the env file
system. This copy is either empty or inherited from this process's parent
at spawn time (depending on the flags to spawn).
To over-ride the number of parity buffers for ALL raid 3's (and set only
72 parity buffers) set
: raid ; setenv RAID3_Default_PBUFS 128
If you set a default for all raid sets of a particular type, but want ONE
of them to be different then set up a variable for that particular raid
set as it's value will over-ride the default. In the above example, where all
Raid Type 3 will have 128 parity buffers, you could set the variable
: raid ; setenv RAID3_Dbase_PBUFS 56
which will allow the raid 3 raid set named 'Dbase' to have 56 parity buffers,
but all other raid 3's defined on the RaidRunner will have 128.
- SEE ALSO: setenv, printenv, rconf, rebuild, internals
- SYNOPSIS: exec [ arg ... ]
- DESCRIPTION: exec causes the command specified by the first arg to be executed
in place of this shell without creating a new process. Subsequent args are
passed to the command specified by the first arg as its arguments. Shell redirection
may appear and, if no other arguments are given, causes the shell input/output
to be modified.
- SYNOPSIS: exit [string]
- DESCRIPTION: exit has an optional string argument. If the optional argument
is given the current K9 process is terminated with the given string as its
exit value. (If the string has embedded spaces then the whole string should
be a quoted_string). If no argument is given then the shell gets the string
associated with the environment variable "status" and returns that
string as the exit value. If the environment variable "status"
is not found then the "true" exit status (i.e. NIL) is returned.
- SEE ALSO: true, K9exit
- SYNOPSIS: expr numeric_expr ...
- DESCRIPTION: expr evaluates each numeric_expr command line argument as
a separate numeric expression. Thus a single expression cannot contain unescaped
whitespaces or needs to be placed in a quoted string (i.e. between "{"
and "}"). Arithmetic is performed on signed integers (currently
numbers in the range from -2,147,483,648 to 2,147,483,647). Successful calculations
cause no output (to either standard out/error or environment variables). So
each useful numeric_expr needs to include an assignment (or op-assignment).
Each numeric_expr argument supplied is evaluated in the order given (i.e. left
to right) until they all evaluate successfully (returning a true status). If
evaluating a numeric_expr fails (usually due to a syntax error) then the expr
command fails with "error" as the exit status and the error message
is written to the environment variable "error".
- OPERATORS: The precedence of each operator is shown following the description
in square brackets. "0" is the highest precedence. Within a single
precedence group evaluation is left-to-right except for assignment operators
which are right-to-left. Parentheses have higher precedence than all operators
and can be used to change the default precedence shown below.
UNARY OPERATORS
+
Does nothing to expression/number to the right.
-
negates expression/number to the right.
!
logically negate expression/number to the right.
~
Bitwise negate expression/number to the right.
BINARY ARITHMETIC OPERATORS
*
Multiply enclosing expressions [2]
/
Integer division of enclosing expressions
%
Modulus of enclosing expressions.
+
Add enclosing expressions
-
Subtract enclosing expressions.
<<
Shift left expression _left_ by number in right expression. Equivalent
to: left * (2 ** right)
>>
Shift left expression _right_ by number in right expression. Equivalent
to: left / (2 ** right)
&
Bitwise AND of enclosing expressions
^
Bitwise exclusive OR of enclosing expressions. [8]
|
Bitwise OR of enclosing expressions. [9]
BINARY LOGICAL OPERATORS
These logical operators yield the number 1 for a true comparison and 0
for a false comparison. For logical ANDs and ORs their left and right expressions
are assumed to be false if 0 otherwise true. Both logical ANDs and ORs evaluate
both their left and right expressions in all case (cf. C's short-circuit action).
<=
true when left less than or equal to right. [5]
>=
true when left greater than or equal to right. [5]
<
true when left less than right. [5]
>
true when left greater than right. [5]
==
true when left equal to right. [6]
!=
true when left not equal to right. [6]
&&
logical AND of enclosing expressions [10]
||
logical OR of enclosing expressions [11]
ASSIGNMENT OPERATORS
In the following descriptions "n" is an environment variable
while "r_exp" is an expression to the right. All assignment operators
have the same precedence which is lower than all other operators. N.B. Multiple
assignment operators group right-to-left (i.e. same as C language).
=
Assign right expression into environment variable on left.
*=
n *= r_exp is equivalent to: n = n * r_exp
/=
n /= r_exp is equivalent to: n = n / r_exp
%=
n %= r_exp is equivalent to: n = n % r_exp
+=
n += r_exp is equivalent to: n = n + r_exp
-=
n -= r_exp is equivalent to: n = n - r_exp
<<=
n <<= r_exp is equivalent to: n = n << r_exp
>>=
n >>= r_exp is equivalent to: n = n >> r_exp
&=
n &= r_exp is equivalent to: n = n & r_exp
|=
n |= r_exp is equivalent to: n = n | r_exp
- NUMBERS: All number are signed integers in the range stated in the description
above. Numbers can be input in base 2 through to base 36. Base 10 is the default
base. The default base can be overridden by:
- a leading "0" : implies octal or hexadecimal
- a number of the form _base_#_num_
Numbers prefixed with "0" are interpreted as octal. Numbers
prefixed with "0x" or "0X" are interpreted as hexadecimal.
For numbers using the "#" notation the _base_ must be in
the range 2 through to 36 inclusive. For bases greater then 10 the letters
"a" through "z" are utilised for the extra "digits".
Upper and lower case letters are acceptable. Any single digit that exceeds
(or is equal to) the base is consider an error. Base 10 numbers only may have
a suffix. See suffix for a list of valid suffixes. Also note that since expr
uses signed integers then "1G" is the largest magnitude number
that can be represented with the "Gigabyte" suffix (assuming 32
bit signed integers, -2G is invalid due to the order of evaluation).
- SYNOPSIS: false
- DESCRIPTION: false does nothing other than return a K9 false status. K9
processes return a pointer to a C string (null terminated array of characters)
on termination. If that pointer is NULL then a true exit value is assumed while
all other returned pointer values are interpreted as false (with the string
being some explanation of what went wrong). This command returns a pointer
to the string "false" as its return value.
- EXAMPLE: The following script fragment will print "got here"
to standard out:
if false then
echo impossible
else
echo got here
end
- SEE ALSO: true
- SYNOPSIS:
- bind -k {fifo size} bind_point
- cat bind_point
- bind_point/data
- bind_point/ctl
- DESCRIPTION: fifo file system associates a one level directory with the
bind_point in the K9 namespace with a buffer size of size bytes. bind_point/data
and bind_point/ctl are the data and control channels for the fifo. Data written
to the bind_point/data file is available for reading from the same file in
a first-in first-out basis. A write of x bytes to the bind_point/data file
will either complete and and transfer all the data, or will transfer sufficient
bytes until the fifo buffer is full then block until data is removed from the
fifo buffer by reading. A read of x bytes from the bind_point/data file will
transfer the lessor of the current amount of data in the fifo buffer or x bytes.
A read from the bind_point/ctl will return the size of the fifo buffer and
the current usage. The number of opens (# Opens) is the number of processes
that currently have the bind_point/data file open.
- EXAMPLE
> /buffer
bind -k {fifo 2048} /buffer
ls -l /buffer
/buffer:
/buffer/ctl fifo 2 0x00000001 1 0
/buffer/data fifo 2 0x00000002 1 0
cat /buffer/ctl
Max: 2048 Cur: 0, # Opens: 0
echo hello > /buffer/data
cat /buffer/ctl
Max: 2048 Cur: 6, # Opens: 0
dd if=/buffer/data bs=512 count=1
hello
0+1 records in
0+1 records out
cat /buffer/ctl
Max: 2048 Cur: 0, # Opens: 0
- SEE ALSO: pipe
- SYNOPSIS: get number [ value ... ]
- DESCRIPTION: get uses the given number to select one value from the given
list. Indexing is origin 0 (e.g. "get 0 aaa bb c" returns "aaa").
If the number is out of range for an index on the given list of values then
nothing is returned.
- SYNOPSIS:
- DESCRIPTION: getiv prints the current value of an internal RaidRunner variable
or prints a list of all variables. When a variable name is given it's current
value is printed. If no value is given the all available internal variables
are listed.
- NOTES: As different models of RaidRunners have different internal variables
see your RaidRunner's Hardware Reference manual for a list of variables together
with the meaning of their values. These variables are run-time variables and
hence revert to their default value whenever the RaidRunner is booted.
- SEE ALSO: setiv
- SYNOPSIS: help or ?
- DESCRIPTION: help or the question mark character - ?, will print a list
of all commands available to the command interpreter. Along with each command,
it's synopsis is printed.
As the file "/env/status" is an environment variable the return
status of a command is also available in the variable $status. The exit
status of a pipeline is the exit status of the last command in the pipeline.
- SIGNALS If an interactive shell receives an interrupt signal (i.e. K9_SIGINT
- usually a control-C on the console) then the shell exits. The "init"
process will then start a new instance of the husky shell with all the previously
running processes (with the exception of the just killed shell) still running.
This allows the user to kill the process that caused the previous shell problems.
Alternatively a process that is acci dentally run in foreground is effectively
put in the background by sending an interrupt signal to the shell. Note that
this is quite different to Unix shells which would forward the signal onto
the foreground process.
- QUOTES, ESCAPING, STRING CONCATENATION, ETC: A quoted_string (as defined
in the grammar) commences with a "{" and finishes with the
matching "}". The term "matching" implies that
all embedded "{" must have a corresponding embedded "}"
before the final "}" is said to match the original "{".
A quoted_string can be spread across several lines. No command line substitution
occurs within quoted_strings. The character for escaping the following character
is "\". If a "{" needs to be interpreted literally
then it can be represented by "\{". If a string containing
spaces (whitespaces) needs to be interpreted as a single token then space
(whitespace) can be escaped (i.e. "\ "). If a "\"
itself needs to be interpreted literally then it can be represented by "\\".
The string concatenation character is "^". This is useful when
a token such as "/d4" needs to built up by a script when "/d"
is fixed and the "4" is derived from some variable:
set n 4
> /d^$n
This example would create the file "/d4".
The output of another husky command or script can be made available inline
by starting the sequence with "`" and finishing it with a "'".
For example:
echo {ps output follows:
} `ps'
This prints the string "ps output follows:" followed on the
next line by the current output from the command "ps". That output
from "ps" would have its embedded newlines replaced by whitespaces.
COMMAND LINE FILE REDIRECTION:
- Redirection should appear after a command and its arguments in a line to
be interpreted by husky. A special case is a line that just contains ">
filename" which creates the filename with zero length if it didn't previously
exist or truncates to zero length if it did.
- Redirection of standard in to come from a file uses the token "<"
with the filename appearing to its right. The default source of standard in
is the console.
- Redirection of standard out to go to a file uses the token ">"
with the filename appearing to its right. The default destination of standard
out is the console.
- Redirection of standard error to go to a file uses the token ">[2]"
with the filename appearing to its right. The default destination of standard
error is the console.
- Redirection of writes from within a command which uses a known file descriptor
number (say "n") to go to a file uses the token ">[n]"
with the filename appearing to its right.
- Redirection of read from within a command which uses a known file descriptor
number (say "n") to come from a file uses the token "<[n]"
with the filename appearing to its right.
- Redirection of reads and writes from within a command which uses a known
file descriptor number (say "n") to a file uses the token "<>[n]"
with the filename appearing to its right. In order to redirect both standard
out and standard error to the one file the form " > filename >[2=1]"
can be used. This sequence first redirects standard out (i.e. file descriptor
1) to filename and then redirects what is written to file descriptor 2 (i.e.
standard error) to file descriptor 1 which is now associated with filename.
ENVIRONMENT VARIABLES: Each process can access the name it was invoked
by via the variable: "arg0" . The command line arguments (excluding
the invocation name) can be accessed as a list in the variable: "argv"
. The number of elements in the list "argv" is place in "argc".
The get command is useful for fetching individual arguments from this list.
The pid of the current process can be fetched from the variable: "pid".
When a script launches a new process in the background then the child's pid
can be accessed from the variable "child". The variable "ContollerId"
is set to the RaidRunner controller number husky is running on. Environment
variables are a separate "space" for each process. Depending on
the way a process was created, its initial set of environment variables may
be copied from its parent process at the "spawn" point.
SEE ALSO: intro
- SYNOPSIS: hwconf [-D] [-M] [-I] [-d
[-n]] [-f] [-h] [-i -p c.s.l]
[-m] [-p c.s.l] [-s] [-S] [-t]
[-T] [-P] [-W]
- DESCRIPTION: hwconf prints details about the RaidRunner hardware and devices
attached.
- OPTIONS:
- -h: Print the number of controllers, host interfaces per controller, the
number of disk channels per controller, number of ranks of disks and the details
memory (in bytes) on each controller. Four memory figures are printed,
the first is the total memory in the controller, next is the amount of memory
at boot time, next is the amount currently available and lastly is the largest
available contiguous area of memory. This is the default option.
- -f: Print the number of fans in the RaidRunner and then the speed for
each fan in the system. The speeds values are in revolutions per minute (rpms).
The fans in the system are labeled in your hardware specification sheet
for your RaidRunner. The first speed printed from this command corresponds
to fan number 0 on your specification sheet, the second is for fan 1, and so
forth.
- -d: Print out information on all the disk drives on the RaidRunner. For
each disk on the RaidRunner, print out - the device name, in the format
c.s.l where c is the channel, s is the SCSI ID (or rank) and l is the SCSI
LUN of the device, the manufacturer's name (vendor id), the disk's model name
(product id), the disk's version id, the disk serial number, the disk geometry
- number of cylinders, heads and sectors, and the last block number on the
disk and the block size in bytes. the disk revolution count per minute (rpm's),
the number of notches/zones available on the drive (if any)
- -n: Print out the disk drive notch/zone tables if available. This is a
sub-option to the -d option. Not all disks appear to correctly report the
notch/zone partition tables. For each notch/zone,
- the following is printed: the zone number, the zone's starting cylinder,
the zone's starting head, the zone's ending cylinder, the zone's ending head,
the zone's starting logical block number, the zone's ending logical block number,
the zone's number of sectors per track
- -D: Print out the device names for all disk drives on the system.
- -I: Initialize back-end NCR SCSI chips. This flag may be used in conjunction
with any other option and will done first. It has an effect only the first
call to hwconf that has not yet used a -d, -D or -I options, or on those chips
that have not yet had a -p on the channel associated with that chip.
- -m: Print out major flash and battery backed-up ram addresses (in hex).
Additionally print out the size of the RaidRunner configuration area. Eight
(8) addresses are printed in order RaidRunner configuration area start and
end addresses (FLASH RAM), RaidRunner Husky Scripts area start and end addresses
(FLASH RAM), RaidRunner Binary Image area start and end addresses (FLASH RAM),
RaidRunner Battery Backed-up area start and end addresses. And the size of
the RaidRunner configuration area (in bytes) is then printed.
- -p c.s.l: Probe a single device specified by the given channel, SCSI ID
(rank) and SCSI LUN provided in the format "c.s.l". The output
of this command is the same as the "-d" option but just for the
given device. If the device is not present then nothing will be output and
the exit status of the command will be 1.
- -i -p c.s.l: Re-initialize the SCSI device driver specified by the given
channel, SCSI ID (rank) and SCSI LUN provided in the format "c.s.l".
Typically this command is used when, on a running RaidRunner, a new drive
is plugged in, and it will be used prior to the RaidRunner's next reboot.
- -M: Set the boottime memory. This option is executed internally by the
controller at boot time and has no function (or effect) executed at any other
time.
- -s: Print the 12 character serial number of the RaidRunner.
- -S: Issue SCSI spin up commands to all backends as quickly as possible.
This option is intended for use at power-on stage only.
- -t: Probe the temperature monitor returning the internal temperature
of the RaidRunner in degrees Celsius.
- -T: Print the temperatures being recorded by the hardware monitoring daemon
(hwmon).
- -P: For both AC and DC power supplies, print the number of each present
and the state of each supply. The state will be printed as ok or flt depending
on whether the PSU is working or faulty.
- -W: This option will wait until all possible backends have spun up.
It is used in conjunction with
- NOTES : The order of printing the disk information is by SCSI ID (rank),
by channel, by SCSI LUN.
- SYNOPSIS: hwmon [-t seconds] [-d]
- DESCRIPTION: hwmon is a hardware monitoring daemon. It periodically
probes the status of certain elements of a RaidRunner and if an out-of-band
occurrence happens, will cause the alarm to sound or light up fault leds
as well as saving a message in the system log. Depending on the model of RaidRunner,
the elements monitored are temperature, fans and power supplies. When an out-of-band
occurrence is found, hwmon will reduce the time between probes to 5 seconds.
If a buzzer is the alarm device, then the buzzer will turn on for 5 seconds
then off for 5 seconds and repeat this cycle until the buzzer is muted or the
occurrence is corrected.
If the RaidRunner model supports a buzzer muting switch, then the buzzer
will be muted if the switch is pressed during a cycle change as per the
previous paragraph. When hwmon recognizes the mute switch it will beep twice.
Certain out-of-band occurrences can be considered to be catastrophic, meaning
if the occurrence remains uncorrected, the RaidRunner's hardware is likely
to be damaged. Occurrences such as total fan failure and sustained high temperature
along with total or partial fan failure are considered as catastrophic. hwmon
has a means of automatically placing the RaidRunner into a "shutdown"
or quiescent state where minimal power is consumed (and hence less heat is
generated). This is done by the execution of the shutdown command after
a period of time where catastrophic out-of-band occurrences are sustained.
This process is enabled, via the AutoShutdownSecs internal variable. See the
internals manual for use of this variable. hwmon can be prevented from
starting at boot time by creating the global environment variable NoHwmon and
setting any value to it. A warning message will be stored in the syslog.
- OPTIONS:
- t seconds: Specify the number of seconds to wait between probes of the
hardware elements. If this option is not specified, the default period is
300 seconds.
- -d: Turn on debugging mode which can produce debugging output.
- SEE ALSO: hwconf, pstatus, syslogd, shutdown, internals
- DESCRIPTION: Certain run-time features of the RaidRunner can be manipulated
by changing internal variables via the setiv command. The table below describes
each changeable variable, it's effect, it's default value and range of values
it can be set to. The variables below are run-time features of a RaidRunner
and hence are always set to their default values when a RaidRunner boots. Certain
variables can be stored as a global environment variable and will over-ride
the defaults at boot time. If you create a global environment variable of
that variable's name with an appropriate value, it's default value will be
over-ridden the next time the RaidRunner is re-booted. Note, that the values
of these variables ARE NOT CHECKED when set in the global environment variable
tables and, if incorrectly set, will generate errors at boot until deleted
or corrected. In the table below, any variable that can have a value stored
as a global environment variable is marked with (GEnv)
- write_limit: This variable is the maximum number of 512-byte blocks
the cache filesystem will buffer for writes. If this limit is reached all writes
to the cache filesystem will be blocked until the cache filesystem has written
out (to it's backend) enough blocks to reach a low water mark - write_low_tide.
This variable cannot be changed if battery backed-up RAM is available as
it is tied to the amount of battery backed-up RAM available. The value of this
variable is calculated when the cache is initialized. It's value is dependant
on whether battery backed-up RAM is installed in the RaidRunner. If installed,
the number of blocks of data that can be saved into the battery backed-up RAM
is calculated. If no battery backed-up RAM is present, it's value is set to
75% of the RaidRunner's memory (expressed in a count of 512 byte
blocks) then adjusted to reflect the amount of cache requested by configured
raid sets. When write_limit is changed then both write_high_tide and write_low_tide
are automatically changed to there default values (a function of the value
of write_limit).
- write_high_tide: This variable is a high water mark for the number of written-to
512-byte blocks in the cache. When the number of data blocks exceeds this value,
to avoid the cache filesystem from blocking it's front end, the cache flushing
mechanism continually flushes the cache buffer until the amount of unwritten
(to the backend) cache buffers is below the low water mark (write_low_tide).
This value defaults to 75% of write_limit. This variable can have values
ranging from write_limit down to write_low_tide. It is recommended that this
variable not be changed.
- write_low_tide: This variable is a low water mark for when the cache flushing
mechanism is continually flushing data to it's backend. Once the number
of written-to cache blocks yet to be flushed equals or is less than this value,
the sustained flushing is stopped. This value defaults to 25% of write_limit.
This variable can have values ranging from write_high_tide-1 down to zero (0).
It is recommended that this variable not be changed.
- cache_nflush: This variable is the number of cache buffers (not 512-byte
data blocks) that the cache flushing mechanism will attempt to write out
in one flush cycle. Adjusting this value may improve performance on writes
depending of the size of the cache buffers and type of disk drives used in
the raid set backends. The default value is 128. It's value can range from
2 to 128.
- cache_nread: This variable is the number of cache buffers (not 512-byte
data blocks) that the cache reading mechanism will attempt to read out in
one read cycle. Adjusting this value may improve performance on reads depending
of the size of the cache buffers and type of disk drives used in the raid set
backends. The default value is 128. It's value can range from 2 to 128.
- cache_wlimit: This variable is the number of cache buffers (not 512-byte
data blocks) that the cache flushing mechanism will attempt coalesce into
a single sequential write. It is different to cache_nflush in that cache_nflush
is the total number of cache buffers that can be written in a single cache
flush cycle and these buffers can be non sequential whereas cache_wlimit
is a limit on the number of sequential cache buffer's that can be written with
one write. Adjusting this value may improve performance on writes depending
of the size of the cache buffers and type of disk drives used in the raid
set backends. The default value is 128. It's value can range from 2 to 128.
- cache_fperiod (GEnv): By default, the cache flushes any data to be written
every 1000 milliseconds (unless it's forced to by the fact that the cache is
getting full and then it flushes the cache and resets the timer). You can
vary this flushing period by setting this variable. Given you have a large
number of sustained reads and minimal writes, then you may want to delay the
writes out of cache to the backends as long as possible. Note, that by setting
this to a high value, you run the risk of loosing what you have written.
The default value is 1000 milliseconds (i.e 1 second). It's value can range
from 500ms to 300000ms.
- scsi_write_thru (GEnv): By default all writes (from a host) are buffered
in the RaidRunner's cache and are flushed to the backend disks periodically.
When battery backed-up RAM is available then this results in the most efficient
write throughput. If no battery backed-up RAM is available or you do not want
to depend on writes being saved in battery backed-up RAM in event of a power
failure you can force the RaidRunner to write data straight thru to the backends
prior to returning an OK status to the host. This essentially provides a write-thru
cache. The default value of this variable is 0 - write-thru mode is DISABLED.
The values this variable can take are
- 0 - DISABLE write-thru mode, or
- 1 - ENABLE write-thru mode.
- scsi_write_fua (GEnv): This variable effects what is done when the FUA
(Force Unit Access) bit is set on a SCSI WRITE-10 command. When this variable
is enabled and a SCSI WRITE-10 command has the FUA bit set is processed
then the data is written directly thru the cache to the backend disks. If the
variable is disabled, then the setting of the FUA bit on SCSI WRITE-10 commands
is ignored. The default value for this variable is disabled (0) if battery
backed-up RAM is present, or enabled (1) if battery backed-up RAM is NOT present.
The values this variable can take are
- 0 - IGNORE FUA bit on SCSI WRITE-10 commands, or
- 1 - ACT on FUA bit on SCSI WRITE-10 commands.
- scsi_ierror (GEnv): This variable controls what is done when the RaidRunner
receives a Initiator Detected Error message on a SCSI host channel. If
set (1), cause an Check Condition, If NOT set (0), follow the SCSI-2 standard
and re-transmit the Data In / Out phase. The default value is 0. The values
this variable can take are
- 0 - follow SCSI-2 standard
- 1 - ignore the SCSI-2 standard and cause a Check Condition.
- scsi_sol_reboot (GEnv): Determines whether to auto-detect a Solaris reboot
and the clear any wide mode negotiations. If set (1), detect a Solaris reboot
and clear wide mode. If NOT set (0), follow the SCSI-2 standard and not
clear wide mode. The default value is 0. The values this variable can take
are
- 0 - follow SCSI-2 standard
- 1 - ignore the SCSI-2 standard and clear wide mode.
- scsi_hreset (GEnv): Determines whether to issue a SCSI bus reset on host
ports after power-on. If set (1), then a SCSI bus reset is done on the host
port when starting the first smon/stargd process on that port. If NOT set
(0), nothing is done. The default value is 0. The values this variable can
take are
- 0 - don't issue SCSI bus resets on power-on.
- 1 - issue SCSI bus resets on power-on when the first smon/stargd process
is started.
- scsi_full_log (GEnv): Determines whether or not stargd reports, via syslog,
a Reset Check condition on Read, Write, Test Unit Ready and Start Stop commands.
This reset check condition is always set when a RaidRunner boots or the raid
detects a scsi-bus reset. Note that this variable only suppresses the logging
of this Check condition into syslog, it does not effect the response to the
host of this and any Check condition. If set (1), then all stargd detected
reset Check condition error messages are logged. If NOT set (0), these messages
are suppressed The default value is 0. The values this variable can take are
- 0 - suppress logging these messages
- 1 - log all messages.
- scsi_ms_badpage (GEnv): Determines whether or not stargd reports, via syslog,
that it has received a non-supported page number in a MODE SENSE or MODE
SELECT command it receives from a host. Note that stargd will issue the appropriate
Check condition to the host ("Invalid Field in CDB") irrespective
of the value of this variable. If set (1), then all stargd detected non-supported
page numbers in MODE SENSE and MODE SELECT commands will be logged. If
NOT set (0), these messages are suppressed The default value is 0. The values
this variable can take are
- 0 - suppress logging these messages
- 1 - log all messages.
- scsi_bechng (GEnv): Determines whether or not the raid reports backend
device parameter change errors. In a multi controller environment, backends
are probed and some of their parameters are changed by a booting controller.
This will generate parameter change mode sense errors. If cleared (0), then
all parameter change errors will NOT be logged. If set (1), these messages
are logged like any other backend error. The default value is 0. The values
this variable can take are
- 0 - suppress logging these messages
- 1 - log all messages.
- scsi_dnotch (GEnv): Some disk drives take an inordinate amount of time
to perform mode select commands. One set of information a RaidRunner
will obtain from a device backend are the disk notch pages (if present). As
this is for information only, then to reduce the boot time of a RaidRunner
you can request that disk notches are not obtained. If cleared (0), backend
disk notch information is not probed for. If set (1), then backend disk notch
information is probed for. The default value is 1. The values this variable
can take are:
- 0 - don't probe for notch pages
- 1 - probe for notch pages
- scsi_rw_retries (GEnv): Specify the number of read or write retries
to perform on a device backend before effecting an error on the given operation.
Note that ALL retries are reported via syslog. The default value is 3. It's
value can range from 1 to 9.
- scsi_errpage_r (GEnv): Specify the number of internal read retries that
a disk backend is to perform before reporting an error (to the raid). Setting
this variable causes the Read Retry Count field in the Read-Write Error Recovery
mode sense page. A value of -1 will cause the drive's default to be used. The
default value is -1. It's value can range from -1 (use disk's default) or from
0 to 255.
- scsi_errpage_w (GEnv): Specify the number of internal write retries that
a disk backend is to perform before reporting an error (to the raid). Setting
this variable causes the Write Retry Count field in the Read-Write Error
Recovery mode sense page. A value of -1 will cause the drive's default to
be used. The default value is -1. It's value can range from -1 (use disk's
default) or from 0 to 255.
- BackFrank: Specify the SCSI-ID of the first rank of backend disks on a
RaidRunner. This variable should never be changed and is for informative
purposes only. The default value is dependant on the model of RaidRunner being
run. The values this variable can take are
- 0 - the first rank SCSI-ID will be 0
- 1 - the first rank SCSI-ID will be 1
- raid_drainwait (GEnv): Specify the number of milliseconds a raidset
is to delay, before draining all backend I/O's when a backend fails. Setting
this variable to a lower value will speed up the commencement of any error
recovery procedures that would be performed on a raid set when a backend
fails. The default value is 500 milliseconds. It's value can range from 50
to 10000 milliseconds.
- EnclosureType: Specify the enclosure type a raid controller is running
within. This variable should never be changed and is for informative purposes
only. The default value is dependant on the model of RaidRunner being run.
The values this variable can take are integers starting from 0.
- fmt_idisc_tmo (GEnv): Specify the SCSI command timeout (in milliseconds)
when a SCSI FORMAT command is issued on a backend. Disk drives take different
amounts of time to perform a SCSI FORMAT command and hence a timeout is required
to be set when the command is issued. As certain drives may take longer to
format than the default timeout you can change it. The default value is 720000
milliseconds. It's value can range from 200000 to 1440000 milliseconds.
- AutoShutdownSecs (GEnv): Specify the number of seconds the RaidRunner
should monitor catastrophic hardware failures before deciding to automatically
shutdown. A catastrophic failure is one which will cause damage to the RaidRunner's
hardware if not fixed immediately. Failures like all fans failing would
be considered catastrophic. A value of 0 seconds (the default) will disable
this feature, that is, with the exception of logging the errors, no action
will occur. See the shutdown and hwmon for further details. The default value
is 0 seconds. It's value can range from 20 to 125 seconds.
- SEE ALSO: setiv, getiv, syslog, setenv, printenv, hwmon, shutdown
- SYNOPSIS: kill [-sig_name] pid
- DESCRIPTION: kill sends a signal to the process nominated by pid. If the
pid is a positive number then only the nominated process is signaled. If the
pid is a negative number then the signal is sent to all processes in the same
process group as the process with the id of -pid. The switch is optional and
if not given a SIGTERM (software termination signal) is sent. If the sig_name
switch is given then it should be one of the following (lower case) abbreviations.
Only the first 3 letters need to be given for the signal name to be recognized.
Following each abbreviation is a brief explanation and the signal number in
brackets:
null - unused signal [0]
hup - hangup [1]
int - interrupt (rubout) [2]
quit - quit (ASCII FS) [3]
kill - kill (cannot be caught or ignored) [4]
pipe - write on a pipe with no one to read it [5]
alrm - alarm clock [6]
term - software termination signal [7]
cld - child process has changed state [8]
nomem - could not obtain memory (from heap) [9]
You cannot kill processes whose process id is between 0 and 5 inclusive.
These are considered sacrosanct - hyena, init and console reader/writers.
- SYNOPSIS:
- led
- led led_id led_function
- DESCRIPTION: led uses the given led_id to identify the LED to manipulate
based on the led_function. When no arguments are given, an internal LED register
is printed along with the current function the onboard LEDS, led1 and led2
are tracing. If a undefined led_id is given, the led command silently does
nothing and returns NULL. If an incorrect number of arguments or invalid led_function
is given a usage message is printed. Depending on the RaidRunner model the
led_id can be one of
- led1 - LED1 on the RaidRunner controller itself
- led2 - LED2 on the RaidRunner controller itself
- Dc.s.l - Device on channel c, scsi id s, scsi lun l
- status - the status LED on the RaidRunner
- io - the io LED on the RaidRunner
and led_function can be one of
- on - turn on the given LED
- off - turn off the given LED
- ok - set the given LED to the defined OK state
- faulty - set the given LED to the defined FAULTY state
- warning - set the given LED to the defined WARNING state
- rebuild - set the given LED to the defined REBUILD state
- tprocsw - set the given LED to trace kernel process switching
- tparity - set the given LED to trace I/O parity generation
- tdisconn - set the given LED to trace host interface disconnect activity
- pid - set the given LED to trace the process pid as it runs
Different models of RaidRunner have various differences in number of LED's
and their functionality. Depending on the type of LED, the ok, faulty, warning
and rebuild functions perform different functions. See your RaidRunner's Hardware
Reference manual to see what LED's exist and what different functions do.
NOTES: Tracing activities can only occur on the `onboard` leds (LED1, LED2).
SEE ALSO: lflash
- SYNOPSIS: lflash led_id period
- DESCRIPTION: lflash uses the given led_id to identify the LED to flash
every period seconds. If a undefined led_id is given, the led command silently
does nothing and returns NULL. Depending on the RaidRunner model the led_id
can be one of:
led1 - LED1 on the RaidRunner controller itself
led2 - LED2 on the RaidRunner controller itself
Dc.s.l - Device on channel c, scsi id s, scsi lun l
status - the status LED on the RaidRunner
io - the io LED on the RaidRunner
- NOTE: The number of seconds must be greater than or equal to 2.
- SEE ALSO: led
- SYNOPSIS: line
- DESCRIPTION: line accomplishes the one line copy by reading up to a newline
character followed by a single K9write.
- SEE ALSO: K9read, K9write
- SYNOPSIS: llength list
- DESCRIPTION: llength returns the number of elements in a given list.
- EXAMPLES: Some simple examples:
set list D1 D2 D3 D4 D5 # create the list
set len `llength $list' # get it's length
echo $len
5
set list {D1 D2 D3 D4 D5} {D6 D7} # create the
list
set len `llength $list' # get it's length
echo $len
2
set list {} # create an empty list
set len `llength $list' # get it's length
echo $len
0
SEE ALSO: zero
- SYNOPSIS: lrange first last list
- DESCRIPTION: lrange returns a list consisting of elements first through
last of list. 0 refers to the first element in the list. If first is greateR
THAN last then the list is extracted in reverse order.
- EXAMPLES: Some simple examples:
set list D1 D2 D3 D4 D5 # create the list
set subl `lrange 0 3 $list' # extract from indices 0 to 3
echo $subl
D1 D2 D3 D4
set subl `lrange 3 1 $list' # extract from indices 3 to 1
echo $subl
D4 D3 D2
set subl `lrange 4 4 $list' # extract from indices 0 to 3
echo $subl # equivalent to get 4 $list
D5
set subl `lrange 3 100 $list'
echo $subl
D4 D5
- SYNOPSIS: ls [ -l ] [ directory... ]
- DESCRIPTION: ls lists the files in the given directory on standard out.
If no directory is given then the root directory (i.e. "/") is
listed. Each file name contained in a directory is put on a separate line.
Each listing has a lead-in line stating which directory is being shown. If
there is more than one directory then they are listed sequentially separated
by a blank line. If the "-l" switch is given then every listed
file has data such as its length and the file system it belongs to shown on
the same line as its name. See the stat command for more information. ls is
not an inbuilt command but a husky script which utilizes cat and stat. The
script source can be found in the file "/bin/ps".
- SEE ALSO: cat, stat
- SYNOPSIS: lsearch pattern list
- DESCRIPTION: lsearch returns the index of the first element in list that
matches pattern or -1 if none. 0 refers to the first element in the list
- EXAMPLES: Some simple examples:
set list D1 D2 D3 D4 D5 # create the list
set idx `lsearch D4 $list' # get index of D4 in list
echo $idx
3
set idx `lsearch D1 $list' # get index of D1 in list
echo $idx
0
set idx `lsearch D8 $list' # get index of D8 in list
echo $idx # equivalent to get 4 $list
-1
- SYNOPSIS: lsubstr find_char replacement_char list
- DESCRIPTION: lsubstr returns a list replacing every find_ch character found
in any element of the list with the replacement_char character. replacement_char
can be NULL which effectively deletes all find_char characters in the list.
- EXAMPLES: Some simple examples:
set list D1 D2 D3 D4 D5 # create the list
set subl `lsubstr D x $list' # replace all D's with x's
echo $subl
x1 x2 x3 x4 x5
set subl `lsubstr D {} $list' # delete all D's
echo $subl
1 2 3 4 5
set list -L -16 # create a list with embedded braces
set subl `lsubstr {} $list' # delete all open braces
set subl `lsubstr {} $subl' # delete all close braces
echo $subl
-L 16
- SYNOPSIS: bind -k {mem first last [ r ]} bind_point
- DESCRIPTION: mem allows machine memory to be accessed as a single K9
file (rather than a file system). The host system's memory is used starting
at the first memory location up to and including the last memory location.
Both first and last need to be given in hexadecimal. If successful the mem
file will appear in the K9 namespace at the bind_point. The stat command will
show it as a normal file with the appropriate size (i.e. last - first + 1).
If the optional "r" is given then only read-only access to the
file is permitted. In a target environment mem can usefully associate battery
backed-up RAM (or ROM) with the K9 namespace. In a Unix environment it is
of limited use (see unixfd instead). In a DOS environment it may be useful
to access memory directly (IO space) but for accessing the DOS console see
doscon. When mem is associated with the partition of Flash RAM that stores
the husky scripts, which is stored compressed, reading from that page will
automatically decompress and return the data as it is read. When mem is associated
with the writable partitions of Flash RAM (configuration partition, husky script
partition and main binary partition) a write to the start of any partition
will erase that partition.
- SEE ALSO: ram
- BUGS: Only a single file rather than a file system can be bound.
The first line indicates the debug mode, either off, on or trace. The
second line indicates the number times a request for memory is made (to Mmalloc()
or Mcalloc() and related functions) and the number of times the memory
allocator is called to free memory (via Mfree()). The difference between these
first two numbers is the total number of currently allocated blocks of memory,
with the number between the '(' and ')' being the total memory requested.
Note that the amount of memory actually assign may be more than requested.
The third line indicates the amount of memory being managed. The second
number is the total memory man aged (i.e. left over after loading the statically
allocated text, data and bss space). The first number is that left over after
various memory allocation tables have been subtracted out from that afore
mention number. The fourth line is the total amount of extra memory assigned
to requests in excess of the actual requested memory as compared with the totals
on line 3.
The fifth line relates to the list of currently allocated memory. The
first number is the number of free entries left and the second is the maximum
table size. Note that the number of currently allocated blocks (third number
on line 2) when added to the first number on line 5 gives the second number
on line 5.
OPTIONS:
- p: Prints the above mentioned five line summary and then the free list.
- P: Prints all the above plus dumps the list of currently allocated memory.
- PP: Prints all the above plus the free bitmap.
The above three options can generate copious output and require a detailed
knowledge of the source to understand their meaning.
off: Turns off memory allocation debugging. This is the default condition
after booting.
on: Turns on memory allocation assertion checking.
trace: Turns on memory allocation assertion checking and traces every memory
allocation / deallocation.
m: Uses Mmalloc() to allocate a block of memory of size bytes.
f: Uses Mfree() to de-allocate a block of memory addressed by ptr.
c: Uses Mcalloc() to allocate a contiguous block of memory consisting
of nel elements each of size bytes.
r: Uses Mrealloc() to re-allocate a block of previously allocated memory,
ptr, changing the allocated size to be size bytes.
SEE ALSO: Unix man pages on malloc()
- SYNOPSIS: mkdir [ directory_name ... ]
- DESCRIPTION: mkdir creates the given directory (or directories). If all
the given directories can be created then NIL is returned as the status; otherwise
the first directory that could not be created is returned (and this command
will continue trying to create directories until the list is exhausted). A
directory cannot be created with a file name that previously existed in the
enclosing directory.
- SYNOPSIS: mkdiskfs disk_directory_root disk_name
- DESCRIPTION: mkdiskfs is a husky script which is used to perform all
the necessary commands to create a disk filesystem given the root of the disk
file system and the name of the disk.
- OPTIONS :
- disk_directory_root: Specify the directory root under which the disk filesystems
are bound. This is typically /dev/hd.
- disk_name: Specify the name of the disk in the format Dc.s.l where c is
the channel, s is the scsi id (or rank) and l is the scsi lun of the disk.
After parsing it's arguments mkdiskfs creates the disk filesystem's bind
point and binds in the disk at that point. set.
SEE ALSO: rconf, scsihdfs
- SYNOPSIS: mkhostfs controller_number host_port host_bus_directory
- DESCRIPTION: mkhostfs is a husky script which is used to perform all the
necessary commands to create a host port filesystem on the given RaidRunner
controller given the root of the host port file systems and the host port
number.
- OPTIONS:
- controller_number: Specify the controller on which the host port filesystem
is to be created.
- host_port: Specify the host port number to create the filesystem for.
- host_bus_directory: Specify the directory root under which host filesystems
are bound. This is typically /dev/hostbus. After parsing it's arguments
mkhostfs finds out what SCSI ID the host port is to present (see hconf and
then binds in the host filesystem. set.
- SEE ALSO: hconf, scsihpfs
- SYNOPSIS: mkraid `rconf -list RaidSetName'
- DESCRIPTION: mkraid is a husky script which is used to perform all the
necessary commands to create and enable host access to a given Raid Set. The
arguments to mkraid is a line of output from a rconf -list command. After
parsing it's arguments mkraid checks to see if a reconstruction was being
performed when the RaidRunner was last operating, and if so, notes this. It
then creates the raid filesystem (see mkraidfs) and adds a cache frontend to
the raid filesystem. It then creates the required host filesystems (see mkhsotfs)
and finally, if a reconstruction had been taking place when the RaidRunner
was last operating, it restarts a reconstruction.
- NOTE: This husky script DOES NOT enable target access (stargd) to the raid
set it creates.
- SEE ALSO: rconf, mkraidfs, mkhostfs
- SYNOPSIS: mkraidfs -r raidtype -n raidname -b backends [-c chunk]
[-i iomode] [-q qlen] [-v] [-C capacity]
[-S]
- DESCRIPTION: mkraidfs is a husky script which is used to perform all the
necessary commands to create a Raid filesystem.
- OPTIONS:
- -r raidtype: Specify the raid type as raidtype for the raid set. Must be
0, 1, 3 or 5.
- -n raidname: Specify the name of the raid set as raidname.
- -b backends: Specify the comma separated list of the raid set's backends
in the format used by rconf.
- -c iosize: Optionally specify the IOSIZE (in bytes) of the raid set.
- -i iomode: Optionally specify the raid set's iomode - read-write, read-only,
write-only.
- -q qlen: Optionally specify the raid set's queue length for each backend.
- -v: Enable verbose mode which prints out the main actions (binding, engage
commands) as they are performed.
- -C capacity: Optionally specify the raid set's size in 512-byte blocks.
- -S: Optionally specify that spares pool access is required should a backend
fail.
After parsing it's arguments mkraidfs creates the Raid Set's backend filesystems,
typically, disks (see mkdisfs) taking care of failed backends. It then
binds in the raid filesystem and engages the backends into the filesystem.
If spares access is requested, it enables the autorepair feature of the raid
set.
SEE ALSO: rconf, mkraidfs, mkhostfs, mkdiskfs, raid[0135]fs
- SYNOPSIS: mksmon controllerno hostport scsi_lun protocol_list
- DESCRIPTION: mksmon is a husky script which is used to perform all the
necessary commands to start the scsi monitor daemon smon given the controller
number, hostport, scsi lun, and the block protocol list. Typically, mksmon,
is run with it's arguments from the output of a mconf -list command.
- OPTIONS:
- controllerno: Specify the controller on which the scsi monitor daemon is
to be run.
- hostport: Specify the host port through which the scsi monitor daemon communicates.
- scsi_lun: Specify the SCSI LUN the scsi monitor daemon is to respond to.
- protocol_list: Specify the comma separated block protocol list the scsi
monitor daemon is to implement.
After parsing it's arguments mksmon checks to see if it's already running
and issues a message if so and exits. Otherwise, it creates the host
filesystem (mkhostfs), creates a memory file and set of fifo's for smon to
use and finally starts smon set.
SEE ALSO: smon, mconf, mkhostfs, fifofs
- SYNOPSIS: mkstargd `rconf -list raidname'
- DESCRIPTION: mkstargd is a husky script which is used to perform all
the necessary commands to start and initialize the scsi target daemon stargd
for a given raid set. Typically, mkstargd, is run with it's arguments from
the output of a rconf -list command. After parsing it's arguments mkstargd
checks to see if it's already running and issues a message if so and exits.
Otherwise, it creates the host filesystem (mkhostfs), then starts the scsi
target daemon (stargd) for the given raid set. stargd is started in a mode
that responds to non-medium access SCSI commands and sets a state of "spinning
up". Typically stargd's are started as soon as possible but do not allow
medium access commands until the underlying raid sets have been created and
then are flagged as "spun up" (via mstargd -o command) which
allows medium access.
- SEE ALSO: stargd, rconf, mkhostfs
- SYNOPSIS: mstargd [-a] [-d level] [-h] [-hr]
[-hw] [-l] [-m] [-n] [-o offset]
[-R] [-s] [-t] [-v] [-W]
[-z] [-Z spinstate] [-U] [-irgap nblks]
pid
- DESCRIPTION: mstargd modifies the state or prints out information about
the stargd daemon with the given pid. If such a process exists and no optional
switches are given then the current debug level of that stargd daemon is printed
to standard out by this call.
mstargd works by looking for file named "/mon/stargd/pid".
If it is not found or the pid does not represent an existing process then
mstargd exits with an appropriate error message. If it is found then it is
assumed to contain a reference into the associated stargd process's state (and
statistics) structure. The "reference" for target hardware such
as the raid (without memory management) is a memory address. The "reference"
for Unix machines could be a shared memory identifier or a memory address (depending
on how K9 processes are mapped to Unix processes).
mstargd performs its monitoring
(or modifying) task then exits immediately. A sanity check is performed on
the associated stargd process's state (and statistics) structure before it
is used. Operations that take a little time (e.g. "-h", "-s"
and "-t") take an internal copy of this state structure. mstargd
is designed to have no detrimental effect on a running stargd daemon. Note
that the 3 modifying operations (i.e. "-o", "-d" and
"-z") have no adverse effect either.
- OPTIONS
- -a: This option has the same effect as giving mstargd the options, "-h
-l -m -s -t".
- -d level: This option will change the debug level of the nominated stargd
daemon to the given level. The debug levels are:
- 0 = no debug messages
- 1 = debug messages on all non-read/write commands
- 2 = debug messages on all commands
- -h: This option will output a histogram for reads and a separate one
for writes. The histogram currently consists of a header line followed by multiple
lines. Each line has the number of blocks in its 1st column, the number
of invocations in the 2nd column and the cumulative time in the SCSI data
phase in the 3rd column. Only lines with non-zero invocations are output.
Block number 257 (if present) will be the last line and records all
commands requesting 257 or more blocks.
- -hr: This option only prints out the histogram for reads.
- -hw: This option only prints out the histogram for writes.
- -l: This option prints out the stargd read lookahead statistics.
- -m: This option prints out the moniker (i.e name) of the raid set indicated
by the given pid.
- -n: This option toggles the collection of statistics by the indicated
stargd process.
- -o offset: This option informs the daemon that reads and writes into
it's store are to be offset by the given number of blocks. The default value
for offset is 0. The given offset must be in the range 0 to (2**32 - 1). The
typical block size is 512 bytes. To simplify writing out large numbers
certain suffixes can be used, see suffix. Additionally, this option informs
the daemon that it's store is now available for access by setting it's spin
state to 1. See "-Z" option below.
- -R: This option sets the write-protect flag which will result in any
write command issued to the stargd process (as indicated by the given pid)
to return a check condition with the sense key set to "DATA PROTECT"
and the additional sense key set to "WRITE PROTECT".
- -s: This option prints the current state of the SCSI command state
machine.
- -t: This option prints a row each for read(6), read(10), write(6),
write(10) and others. These 5 rows represent a categorization of all incoming
SCSI commands. Each row contains the number of invocations and the number of
errors detected. Errors are divided into 2 categories: type 1 for situations
when a "Check Condition" status is returned, and type 2 when
some other failed status is returned (e.g. "Command terminated"
or "Reservation conflict").
- -v: This option prints out the histogram (-h, -hw, -hr) and SCSI command
summary (-t) in vector (or line) form.
- -U: This option clears any SCSI-2 reservations set on the scsi target
specified by the given pid. WARNING this clearance "controller system
wide".
- -W: This option clears the write-protect flag which enables write commands
issued to the stargd process (as indicated by the given pid) to write data.
- -z: This option zeroes the internal tables used by the histograms.
- -irgap nblks: Specify the inter-read gap, nblks, (in blocks). When sequential
reads arrive from a host there may be a small gap between successive reads.
Normally the lookahead algorithm will ignore these gaps providing they
are no larger than the average length of the group of sequential reads that
have occurred. By specifying this value, you can increase this gap.
- -Z spinstate: This option will change the spin state of the nominated
stargd daemon to the given spinstate. The spin states are (State, Description,
ASC,ASCQ):
- 0, LOGICAL UNIT IS IN PROCESS OF BECOMING READY, 0x04, 0x01
- 1, Logical unit is ready - medium access commands allowed, -, -
- 2, LOGICAL UNIT NOT READY, MANUAL INTERVENTION REQUIRED, 0x04, 0x03
- 3, LOGICAL UNIT HAS NOT SELF-CONFIGURED YET, 0x3e, 0x00
- 4, LOGICAL UNIT HAS FAILED SELF-CONFIGURATION, 0x4c, 0x00
- stargd's spin state is used to describe the condition of the tar get
whilst is is NOT READY. When stargd is not ready to accept SCSI-2 medium
access commands it returns a CHECK CONDITION status to all medium access
commands, sets the mode sense key to NOT READY and the additional mode sense
code and code qualifier to values depending in the spin state value.
Typically, when a RaidRunner boots it requires time to create the configured
Raid Sets, although it needs to start the scsi target daemons (stargd) as
soon as possible. It does start all the required stargds and set's their
spin state to 0. Once the raid sets have been built and are linked to their
stargds, the spin state is set to 1 meaning it will allow and process SCSI-2
medium access commands. (See the "-o" option above). The additional
spin states of 2, 3 and 4 can be used by systems with intelligent SCSI drivers
in high availability environments.
- SEE ALSO: stargd
- SYNOPSIS: nice pid priority
- DESCRIPTION: nice will change the run-queue priority of the process given
by pid to priority.
- OPTIONS:
- pid: This is the process identifier of the K9 process whose run-queue
priority is to change.
- priority: This the the priority to set. Priorities range from 0 (lowest)
to 9 (highest).
- SEE ALSO: K9setpriority
- SYNOPSIS: bind -k null bind_point
- DESCRIPTION: null is a special file that when written to is a infinite
sink of data (i.e. anything can be written to it and it will be disposed of
quickly). When null is read it is an infinite source of end-of-files. The null
file will appear in the K9 names- pace at the bind_point.
- EXAMPLE Husky installs a null special file as follows:
bind null /dev/null
SEE ALSO zero, log
- SYNOPSIS: paracc
- DESCRIPTION: paracc will print (to standard output) information about the
hardware parity accelerator, if installed. The main output line of interest
to all except those debugging the RaidRunner is the first line which displays,
in bytes, the size of the memory on the hardward parity accelerator. IE
Parity Memory available : 1048576
PAccLock@0xBF368{own=-1,cnt=1,pvt=0x0,nwait=0,name="PAc"}
Request failures: 0, Max Usage: 2, Alloc: 1, Free: 31
have_paracc is 1.
Req Fails: 0 0 0 0 0 0 0 0 0 0
All other lines are only informative for debugging purposes. If there
is no accelerator present, then the Parity Memory available will be 0.
- SYNOPSIS:
- pedit page_code c.s.l
- pedit page_code c.s.l byte_modifier_list
- DESCRIPTION: pedit will either report the SCSI pages of mode parameters
for a given page - page_code on a given SCSI backend device c.s.l and or allow
you to change the mode parameters. In it's first form, pedit, for a given page
code, will print five lines. The first is a header for ease of reading,
the second will be the DEFAULT mode parameters, the second will be CHANGEABLE
bitmask values, the third will be the CURRENT mode parameters and the last
will be the SAVED mode parameters. In it's second form, pedit, for a given
page code and device, will print the page codes but also will apply the
byte_modifier_list to either the CURRENT or SAVED mode parameters. The supported
SCSI pages are
0x1 ERROR RECOVERY page
0x2 DISCONNECT page
0x3 FORMAT page
0x4 GEOMETRY page
0x8 CACHE page
0xc NOTCH page
0xa CONTROL page
- OPTIONS
- page_code: Specify the SCSI Page Code in hex.
- c.s.l: Identify the disk device to select by specifying it's channel,
SCSI ID (rank) and SCSI LUN provided in the format "c.s.l"
- byte_modifier_list: The byte_modifier_list is of the form
C|Sbyte_no:set_val: clr_val,byte_no:set_val:clr_val,...
where the C or S prefix specifies whether you want to change the CURRENT
or SAVED mode pages respectively. This prefix is followed by a comma separated
list of byte modifiers in the form byte_no:set_val:clr_val where byte_no is
the byte number to change, set_val is a mask of which bits within that byte
to SET (to 1) and clr_val is a mask of which bits within that byte to CLEAR
(to 0).
SEE ALSO: The mode sense page references in the relevant product manual
for the disks used in the RAID.
- SYNOPSIS:
- bind -k pipe bind_point
- cat bind_point
- bind_point/data
- bind_point/ctl
- bind_point/data1
- bind_point/ctl1
- DESCRIPTION: pipe file system associates a one level directory with the
bind_point in the K9 namespace. This device allocates two streams which are
joined at the device end. bind_point/data and bind_point/ctl are the data and
control channels for one stream while bind_point/data1 and bind_point/ctl1
are the data and control channels for the other stream. Data written to
one channel is available for reading at the other. Write boundaries are preserved:
each read terminates when the read buffer is full or after reading the last
byte of a write, whichever comes first.
- SYNOPSIS
- pranks
- pranks rank1 [rank2 ... rankn]
- DESCRIPTION: pranks, without any arguments will print which backend ranks
of devices the controller, on which the command is executed, can access. If
a rank is not accessible, then a "-1" is printed in place of the
rank number (i.e scsi id of that rank). If you wish to set which rank id's
a controller is allowed to access then execute this command with those rank
id's as it's arguments.
When you execute this command to set access to certain (or all) ranks,
then the access restrictions (if any) are effective immediately. Additionally,
the GLOBAL environment variable BackendRanks is either defined or modified
and when you next boot the RaidRunner, the settings you have just created will
be set again automatically.
- EXAMPLE: Assume you have a RaidRunner system with four ranks of backend
devices (rank 1, 2, 3 and 4) but you want to restrict the controller's access
to the first two as you don't have any devices installed in the third and
forth ranks. You would execute pranks 1 2
- SEE ALSO: environ, sranks
- SYNOPSIS
- printenv
- printenv name [name ...]
- DESCRIPTION: printenv prints the value (or list of values) associated with
the GLOBAL environment variable name. If multiple GLOBAL environment variables
are given, each value is printed on a line of it's own. When a GLOBAL environment
variable is a list of values, each value is printed on a line of it's own.
When printenv is called with no arguments, all GLOBAL environment variables
and their associated value(s) are printed, one per line. If a value is a list
then each element of the list is separated with the vertical bar () character.
- NOTE: A GLOBAL environment variable is one which is stored in a non
volatile area on the RaidRunner and hence is available between successive
power cycles or reboots. These variables ARE NOT the same as husky environment
variables. The non volatile area is co-located with the RaidRunner Configuration
area. If the given variable name is not a GLOBAL environment variable nothing
is printed and no error status is set.
- SEE ALSO: setenv, unsetenv, rconf
- PROC - the process file system (device)
- SYNOPSIS:
- bind -k proc bind_point
- cat bind_point
- cat bind_point/0
- cat bind_point/1
- ...
- cat bind_point/N
- signal
- sigpgrp
- status
- DESCRIPTION: The proc device creates a two level directory below its bind_point.
The first level entries are the numbers of the processes that are known currently
to K9. The second level entries are the filenames: "signal", "sigpgrp"
and "status". It is an error to read from the second level directory
files "signal" and "sigpgrp". When "status"
is read it returns an ASCII string containing the following fields:
- process name
- process identifier (i.e. its pid)
- this process's parent's pid
- pid of process group leader
- process state
- process priority
- maximum stack utilization as % of available stack
- milliseconds of CPU time registered
- semaphore id (if any) this process is waiting on
These fields have an appropriate number of spaces between them so they
look "reasonable" when output by ps. The process states are listed
below:
- I interrupted
- R currently running (or has yielded control)
- S stirred (signaled while waiting)
- W waiting on a semaphore
- Z terminated and parent not waiting
It is an error to write to the second level directory file "status".
A signal number or signal name (see kill for a list of signal names - which
cannot be abbreviated in this case) may be written to the file "signal".
This action will send a signal to the associated process. If a signal number
or name is written to the file "sigpgrp" then all the processes
in the process group which this process belongs to will receive the signal.
SEE ALSO: ps, kill
- SYNOPSIS: ps
- DESCRIPTION: ps prints information about all running K9 processes on
standard out. The information output includes the process name, its process
identification number (PID), its parent's PID, process group, process state,
the maximum percentage utilization of its stack and the milliseconds of CPU
time its has used. The process states are listed below:
- I interrupted
- R currently running (or has yielded control)
- S stirred (signaled while waiting)
- W waiting on a semaphore
- Z terminated and parent not waiting
- Currently ps is implemented as a K9 Husky script (rather than a built
in command). The script source can be found in the file "/bin/ps".
The script utilizes the file system proc.
- EXAMPLE:
: raid; ps
NAME____________________PID__PPID__PGRP_S_P_ST%_TIME(ms)__SEMAPHORE+name
hyena 0 0 0 R 9 18 385930 deadbeef
init 1 0 1 W 0 9 90 8009b1a8 pau
SCN2681_reader 4 1 4 W 0 0 0 800702a4 2rd
SCN2681_writer 5 1 5 W 0 0 0 8007029c 2wr
SCN2681_putter 6 1 6 W 0 0 0 800702ac 2tp
DIO_R_drive3_q0 391 1 391 W 0 4 40120 8021a828 Ard
DIO_R_drive0_q0 397 1 397 W 0 4 13420 8007ac64 Ard
DIO_R_drive1_q0 404 1 404 W 0 5 25570 8007b224 Ard
husky 28 1 1 W 0 10 50 8013a138 pau
cache_flusher 424 1 424 W 0 23 17700 8030c2c4 Cfr
CIO_R_q0 426 1 426 W 0 96 2320 8030d6f4 Ard
CIO_R_q1 427 426 426 W 0 96 2420 8030d6f4 Ard
CIO_R_q2 428 426 426 W 0 96 2410 8030d6f4 Ard
CIO_R_q3 429 426 426 W 0 96 2430 8030d6f4 Ard
CIO_R_q4 430 426 426 W 0 96 2240 8030d6f4 Ard
CIO_R_q5 431 426 426 W 0 96 2130 80c37540 Ard
CIO_R_q6 432 426 426 W 0 96 2300 8030d6f4 Ard
CIO_R_q7 433 426 426 W 0 96 2180 8030d6f4 Ard
smon 65 1 1 W 0 5 30 8008d5e4 Nsl
DIO_R_drive2_q0 326 1 326 W 0 5 27680 8007b7e4 Ard
/bin/ps 871 28 1 W 0 8 40 80cfd020 pau
stargd 107 1 1 R 0 48 23990 8007a648 Nsl
starg_107_L_R 119 107 119 W 0 0 0 8018c608 pau
- The fields are: process name, process identifier (i.e. its pid), this process's
parent's pid, pid of process group leader, process state, process priority,
maximum stack utilization as % of available stack, milliseconds of CPU
time registered, semaphore id (if any) this process is waiting on along with
the internal name of the semaphore. If a process is waiting on a semaphore
then the last number is the address of the number it is waiting on.
- SEE ALSO: proc
- SYNOPSIS:
- pscsires
- pscsires moniker
- DESCRIPTION: pscsires looks up the Global SCSI-2 Reservation table for
a given moniker (see smon or stargd) and prints is current SCSI-2 reservation
state. When no moniker is given, all entries in the Global SCSI-2 Reservation
table are printed. For each table entry to be displayed, the moniker and four
integers are printed - the controller number, host port number, reserved
scsi id and reservor scsi id. The combination of controller number, host
port number, and reservor scsi id can uniquely identify which host system
issued the SCSI-2 Reserve command. The reserved scsi id field is used when
a Third-Party reservation has been requested by the host system identified
by the other three integers. If all four integers are -1, then no scsi target
daemon (smon or stargd) on any controller or host port has reserved
the moniker.
- SEE ALSO: smon, stargd, mstargd, SCSI-2 Reserve and Release Command Documentation
- SYNOPSIS: pstatus
- DESCRIPTION: pstatus will print the names and values of various hardware
status registers. Each value is printed on a lineof it's own. Typical hardware
status registers are BCDSW_0, BCDSW_1. Values of BCD host port SCSI ID selector
switches
- FANS: Value of Fan status register
- AC_PWR: Value of AC Power supply status
- DC_PWR: Value of DC Power supply status
- NOTE: Not all RaidRunner models support the same status registers, so consult
you RaidRunner model's hardware reference manual to see which are supported
and what their values imply.
- SYNOPSIS: raidaction raidname up|down|getstats|getastats|zerostats
- DESCRIPTION: raidaction is a husky script which is used to either start
or stop a raid set's scsi target daemon(s) (stargd) or gather/reset statistics
about the raid set.
- OPTIONS :
- raidset: Specify the raid set to perform the action on.
- up: Start all the scsi target daemons associated with this raid set.
- down: Stop all the scsi target daemons associated with this raid set.
- getstats: Print the current statistics stored for the given raid set.
The first line of output is prefixed with the string "RAIDSET:"
and is the output of the stats command with arguments -r raidname -g. The
second line of output is prefixed with the string "CACHE:" and
is the output of the stats command with arguments -c raidname -g. The next
line(s) are prefixed with the string "STARG: c.h.l" and is the
output of the mstargd command with arguments -d 0 -v -h -H stargd_pid which
stargd_pid is the process id of the scsi target daemon on controller c, host
port h with scsi lun l. A line of this type is printed for each scsi target
daemon belonging to this raid set.
- getastats: Print the current statistics stored for the given raid set then
zero all the stored statistics. By zeroing the stored statistics one can,
through repeated timed calls to this code, form an average based on the gathered
statistics. The output is the same as for the getstats option.
- zerostats: Zero all statistics stored for the given raid set.
- SEE ALSO: stats, mstargd
- SYNOPSIS:
bind -k {raid0 nbackends} bind_point
echo moniker name=raid_set_name > bind_point/ctl
echo engage drive=driveNum qlen=queueLen fd=aFdNum blksize=blockSize name=backendname
<>[aFdNum] backEnd > bind_point/ctl
echo disengage drive=driveNum > bind_point/ctl
echo access drive=driveNum read-write > bind_point/ctl
echo access drive=driveNum read-only > bind_point/ctl
echo access drive=driveNum write-only > bind_point/ctl
echo access drive=driveNum offline > bind_point/ctl
cat bind_point
ctl
data
repair
stats
DESCRIPTION: raid0 implements a raid 0 device. It has 1 "frontend"
(i.e. bind_point/data) and typically multiple "backends" (i.e.
one defined by each "engage" message with a new drive number).
To associate an internal name (or moniker) with the raid device, send the message
"moniker name=internal_name" to the device's control file,
bind_point/ctl. This implementation of raid 0 uses nbackends files
in its backend. Read and write operations to the frontend (i.e. bind_point/data)
must be in integral units of blockSize. Each write of blockSize bytes is written
on 1 backend file. The backend "files" referred to here will typically
be disks. The name argument allows associates the given backendname string
with the appropriate backend. This string will be used in reporting errors
on the running raid.
The queueLen argument must be 1 or greater and sets the maximum number
of requests that can be put in a queue associated with each backend file.
A daemon is spawned for each backend file to service this queue called async_io.
Each backend file first needs to be identified to the raid0 device via
the "engage" string sent to bind_point/ctl. If required a file
can have its association with this device terminated with a "disengage"
string. Once a backend file is engaged its access level can be
varied between "read-write", "read-only", "write-only"
and "offline" as required. The default is "offline"
so in most initialization situations an "access read-write" string
needs to be sent to this device. When the file bind_point/ctl is read then
a line is output for every engaged backend file indicating its access status
(e.g. "drive 3: engaged, read-write"). Also backend files
that have been disengaged and not "re-"engaged output a line (e.g.
"drive 5: disengaged").
When the file bind_point/stats is read then a line is output which shows
the cumulative number of reads and writes performed (including failures) for
each backend of the raid device. The format of this line is D0 r0_cnt r0_fails
w0_cnt w0_fails; D1 r1_cnt r1_fails w1_cnt w1_fails; ... which indicates
that backend 0 (typically the drive0) has made r0_cnt reads, w0_cnt writes,
r0_fails read failures and w0_fails write failures and that backend 1 (drive
1) has made r1_cnt reads, w1_cnt writes, r1_fails read failures and
w1_fails write failures and so forth for each backend in the raid set.
If the string "zerostats" is written to the file bind_point/stats
then all cumulative read and write counts for each backend of the raid set
are zeroed.
- EXAMPLE:
> /raid0
bind -k {raid0 6} /raid0
echo moniker name=R_0 > /raid0/ctl
echo engage drive=0 qlen=8 fd=7 blksize=8192 name=D0
<>[7] /d0/data > /raid0/ctl
echo access drive=0 read-write > /raid0/ctl
...
echo engage drive=5 qlen=8 fd=7 blksize=8192 name=D5
<>[7] /d5/data > /raid0/ctl
echo access drive=5 read-write > /raid0/ctl
This example creates the file "/raid0" as a bind point and
then binds the raid0 device on it. The first echo command establishes the
internal raid device name as R_0. The subsequent echo commands are shown in
pairs for each backend file: one sending an "engage" string and
the other sending an "access" string to the file "/raid0/ctl".
Each "engage" string associates a backend file (via file descriptor
7) with a block size of 8192 bytes and a maximum queue length of 8. The following
"access" string adjusts the access level of the backend file from
"offline" (the default) to "read-write". This is a
six disk raid set.
NOTES: The size of the resultant raid set will be the size of the smallest
backend multiplied by the number of data backends adjusted downwards to align
to be a multiple of the raid set's blocksize (blockSize).
SEE ALSO: raid1, raid3, raid4, raid5
- SYNOPSIS:
bind -k raid1 bind_point
echo moniker name=raid_set_name > bind_point/ctl
echo engage drive=driveNum qlen=queueLen fd=aFdNum blksize=blockSize name=backendname
<>[aFdNum] backEnd > bind_point/ctl
echo disengage drive=driveNum > bind_point/ctl
echo access drive=driveNum read-write > bind_point/ctl
echo access drive=driveNum read-only > bind_point/ctl
echo access drive=driveNum write-only > bind_point/ctl
echo access drive=driveNum offline > bind_point/ctl
cat bind_point
ctl
data
repair
stats
DESCRIPTION: raid1 implements a raid 1 device. Raid 1 is also known
as "mirroring". It has 1 "frontend" (i.e. bind_point/data)
and 2 "backends" (i.e. one defined by each "engage"
message with a new drive number). To associate an internal name (or moniker)
with the raid device, send the message "moniker name=internal_name"
to the device's control file, bind_point/ctl. Read and write operations
to the frontend (i.e. bind_point/data) must be in integral units of blockSize.
Each write of blockSize bytes is written on both backend files. A read of
blockSize bytes needs only to read 1 backend file (unless there is a problem).
The backend file chosen to do the read is the one calculated to have its heads
closer to the required block. The backend "files" referred to here
will typically be disks.
The "logical" block size is currently 512 bytes and the given
blockSize must be a power of 2 times 512 (i.e. 2**n * 512 bytes). If,
for example, the blockSize was 8 Kb then a write of 8 Kb would cause both backend
files to have that 8 Kb written to them. An 8 Kb read would cause the file
calculated to have its "heads" closer to be read. If this file
was marked "offline", "write-only" or reported an
IO error then the other file would be read.
The queueLen argument must be 1 or greater and sets the maximum number
of requests that can be put in a queue associated with each backend file. A
daemon is spawned for each backend file to service this queue called async_io.
The name argument allows associates the given backendname string with the appropriate
backend. This string will be used in reporting errors on the running raid.
Each backend file first needs to be identified to the raid1 device
via the "engage" string sent to bind_point/ctl. If required a file
can have its association with this device terminated with a "disengage"
string. Once a backend file is engaged its access level can be
varied between "read-write", "read-only", "write-only"
and "offline" as required. The default is "offline"
so in most initialization situations an "access read-write" string
needs to be sent to this device.
When the file bind_point/ctl is read then a line is output for every engaged
backend file indicating its access status (e.g. "drive 3: engaged, read-write").
Also backend files that have been disengaged and not "re-"engaged
output a line (e.g. "drive 5: disengaged").
When the file bind_point/stats is read then a line is output which shows
the cumulative number of reads and writes performed (including failures) for
each backend of the raid device. The format of this line is:
D0 r0_cnt r0_fails w0_cnt w0_fails; D1 r1_cnt r1_fails w1_cnt w1_fails;
which indicates that backend 0 (typically the drive0) has made r0_cnt
reads, w0_cnt writes, r0_fails read failures and w0_fails write failures and
that backend 1 (drive 1) has made r1_cnt reads, w1_cnt writes, r1_fails
read failures and w1_fails write failures.
If the string "zerostats" is written to the file bind_point/stats
then all cumulative read and write counts for each backend of the raid set
are zeroed.
- EXAMPLE
> /raid1
bind -k raid1 /raid1
echo moniker name=R_1 > /raid1/ctl
echo engage drive=0 qlen=8 fd=7 blksize=8192 name=D1
<>[7] /d0/data > /raid1/ctl
echo access drive=0 read-write > /raid1/ctl
echo engage drive=1 qlen=8 fd=7 blksize=8192 name=D5
<>[7] /d5/data > /raid1/ctl
echo access drive=1 read-write > /raid1/ctl
This example creates the file "/raid1" as a bind point and
then binds the raid1 device on it. The first echo command
establishes the internal raid device name as R_1. The subsequent
echo commands are shown in pairs for both backend files: one sending an "engage"
string and the other sending an "access" string to the file
"/raid1/ctl". Each "engage" string associates
a backend file (via file descriptor 7) with a block size of 8192 bytes and
a maximum queue length of 8. The following "access" string adjusts
the access level of the backend file from "offline" (the default)
to "read-write".
NOTES: The size of the resultant raid set will be the size of the smallest
backend multiplied by the number of data backends (here just 1 as we are a
mirror) adjusted downwards to align to be a multiple of the raid set's blocksize
(blockSize).
SEE ALSO: raid0, raid3, raid4, raid5
- SYNOPSIS
bind -k {raid3 nbackends} bind_point
echo moniker name=raid_set_name > bind_point/ctl
echo engage drive=driveNum qlen=queueLen fd=aFdNum blksize=blockSize name=backendname
<>[aFdNum] backEnd > bind_point/ctl
echo disengage drive=driveNum > bind_point/ctl
echo access drive=driveNum read-write > bind_point/ctl
echo access drive=driveNum read-only > bind_point/ctl
echo access drive=driveNum write-only > bind_point/ctl
echo access drive=driveNum offline > bind_point/ctl
cat bind_point
ctl
data
repair
stats
DESCRIPTION: raid3 implements a raid 3 device. It has 1 "frontend"
(i.e. bind_point/data) and typically multiple "backends" (i.e.
one defined by each "engage" message with a new drive number).
To associate an internal name (or moniker) with the raid device, send
the message "moniker name=internal_name" to the device's
control file, bind_point/ctl.
This implementation of raid 3 uses at least 3 files in its backend.
Read and write operations to the frontend (i.e. bind_point/data) must be in
integral units of blockSize. Each write of blockSize bytes is striped (i.e.
divided evenly) across (nbackends - 1) files with the "parity"
on the other file. Subsequent writes will NOT rotate the file being used to
store parity. [This rotation is a slight extension of the original raid
3 definition.] The backend "files" referred to here will
typically be disks.
The "logical" block size is currently 512 bytes and the
given blockSize must be an integral multiple of (nbackends - 1) * 512 If, for
example, the blockSize was 8 Kb and there were 5 backends then a write of 8
Kb would cause 4 backend files to have 2 Kb written on them and the other
backend file to have 2 Kb of parity written on it. An 8 Kb read would cause
the 4 files known to hold the data (as distinct from the parity) to be read.
If any one of these files was marked "offline", "write-only"
or reported an IO error then the 5th file containing the parity would be read
and the 8 Kb block reconstructed.
The queueLen argument must be 1 or greater and sets the maximum number
of requests that can be put in a queue associated with each backend file.
A daemon is spawned for each backend file to service this queue called async_io.
The name argument allows associates the given backe