admpdisk(1M) DG/UX R4.11MU05 admpdisk(1M)
NAME
admpdisk - administer physical disks
SYNOPSIS
admpdisk -o { list | install | initialize | configure | deconfigure |
convert | register | deregister | cluster | uncluster }
{ options } device_spec ...
admpdisk -o { partition | departition | set_boot_partition }
{ options } -i partition_id device_spec ...
admpdisk -o copy { options } -s source -d destination
admpdisk -o { get_defaults | set_defaults | repair_vdit } { options }
device_spec
admpdisk -o { list_mapped_blocks | verify } { options } { -B
blockno_list } device_spec ...
admpdisk -o { map_block | unmap_block } { options } { -B
blockno_list } device_spec
DESCRIPTION
The admpdisk command displays information about, and manages,
physical disks. For the purposes of this document, a physical disk
is anything for which an entry appears in /dev/pdsk. This includes
traditional single-spindle magnetic disks, floppy disks, and CD-ROMs.
In addition, a single unit in a disk array, such as a Clariion, is
considered here to be a single physical disk, even if it is made up
of multiple removable disk drives; see the documentation for your
disk array hardware for a description of units.
Physical disks are rarely used directly, although each physical disk
does have an entry in /dev/pdsk and /dev/rpdsk through which it can
be accessed. However, access through these special files does not
benefit from software bad block mapping (see below). Normally, the
space on a physical disk is apportioned to one or more virtual disks
(see admvdisk(1M)), and these virtual disks are accessed directly, or
mounted as file systems. Virtual disk partitions can have bad block
mapping described below enabled or disabled, as desired.
Normally, each physical disk has tables that contain information
necessary for maintaining the layout of virtual disks, bad block
maps, the system bootstrap program, and so on.
In addition, each disk usually has a bad block map partition, whose
blocks are used as substitutes for blocks on the disk that have media
defects. Physical disk devices that provide an exceptional level of
reliability, such as RAID-5 disk arrays, generally do not need
software bad block mapping.
Physical Disk Formats
Physical disks that have been initialized under DG/UX release
5.4R3.00 or later are said to be in virtual disk format, that is,
they can contain virtual disks. Physical disks that were initialized
under releases of DG/UX prior to 5.4R3.00, and have not been
converted, as well as CD-ROMs designed to be compatible with such
older releases of DG/UX, contain a different set of system
information. Such physical disks (including CD-ROMs) contain logical
(as opposed to virtual) disks, and are said to be initialized for
logical disks, or in logical disk format.
On the 88K platform, writable physical disks in logical disk format
can be converted to virtual disk format and, under certain
circumstances, converted back (see the convert operation). Read-only
physical disks (such as CD-ROMs) cannot be converted, but can be
registered in compatibility mode (see below).
Physical disks and CD-ROMs in logical disk format can be registered
in compatibility mode. When so registered, temporary virtual disks
are created that mimic the logical disks defined on the physical
disks, so that the data blocks associated with the logical disks may
be mounted, read and written. However, the virtual disks may not be
permanently deleted, expanded, shrunk, or otherwise modified. They
also should not, in general, be incorporated as children into any
other virtual disk, although the system may not prevent you from
doing so. Note that when registering in compatibility mode, no
mirror virtual disks are created to mimic any mirrors defined on the
physical disk, nor cache virtual disks created to mimic any caches
defined on the physical disk.
On the Intel platform, physical disks and CD-ROMs that contain
logical disks are not supported.
Currently, a physical disk initialized on one DG/UX platform cannot
be registered by another. If data is to be moved, it should be
archived to tape using the appropriate archiving utility and
reloaded.
Clustered Physical Disks
A clustered physical disk is a physical disk that resides on a shared
bus (e.g. SCSI bus) and is enabled for concurrent access by all
nodes within a DG/UX cluster. Clustered physical disks are a feature
provided by the DG/UX Cluster package which must be purchased
separately from the DG/UX® System product. Clusters is an optional
DG/UX add-on that will automate many features of system resource
management, failover, and high availability. A DG/UX cluster is a
group of two or more interconnected computer systems (referred to as
nodes) acting together in a closely coordinated way. A cluster does
what a server in a client/server environment does: manages computing
resources and provides services to clients.
Only registered physical disks that reside on a shared bus may be
clustered using the admpdisk -o cluster operation. The clustered
attribute is persistent and is marked on the physical disk itself.
Subsequent deregistrations and registrations on any or all nodes as
well as system reboots will not alter the setting. Only an admpdisk
-o uncluster operation reverses this attribute.
Clustered physical disks have restrictions in the higher-level disk
structures they may contain. In general, you can create virtual disk
partitions (including bad block remapping) and aggregations; see
admvdisk(1M) for details. Currently, virtual disk mirrors and caches
are not supported on clustered disks. The admpdisk command will not
cluster a physical disk if it contains virtual disks of types other
than the following:
· Physical [vdmphys(7) subdriver]
· Partition [vdmpart(7) subdriver]
· Aggregation [vdmaggr(7) subdriver]
· Remap [vdmremap(7) subdriver]
On a non-cluster system (a system that does not have the DG/UX
cluster package installed), a physical disk cannot be clustered.
Furthermore, a clustered physical disk moved to a non-cluster system
cannot be registered. Be sure that any physical disk moved to a non-
cluster system is not clustered.
A physical disk that resides on a shared bus and has not been
clustered can be opened (or registered) by one node only and is said
to be "owned" by that node. Once so owned, the physical disk can be
configured by other nodes, but that's all: the other nodes can't
initialize, read, or write to it. If the first node closes all its
descriptors to the physical disk (which generally includes
deregistering the disk), the node ceases to own the physical disk,
and the physical disk becomes available for access by another node.
A node can gain access to a physical disk that is owned by another
node by using admpdisk -o register -f (the force option), effectively
stealing the physical disk from the other node. Normally this would
be done only if the other node had crashed without relinquishing
ownership of the physical disk.
In contrast, clustered physical disks are not owned by any node. All
nodes in a cluster can read, write, and register clustered physical
disks. Concurrency of management operations on clustered physical
disks between nodes is controlled by the Virtual Disk Manager (see
vdm(7)).
Virtual disks that resides on a clustered physical disks may be
opened and accessed by multiple nodes. In general, the DG/UX
operating system will not synchronize reads and writes between nodes.
Programs must provide their own mechanisms for synchronizing I/O
across nodes to such virtual disks, where needed. Currently, the
operating system will provide synchronized I/O between nodes only for
a virtual disk mounted as a dg/cfs type file system (see mount(1M)).
Cluster-Wide Device Names
Ordinarily, physical disks are specified by their common device
specification (e.g. "sd(ncsc(0,7),0,0)"); for a description of these,
see Managing the DG/UX System. These names are derived from the way
the device is connected to the machine, i.e. the name and number of
the controller, and the setting of switches in the device. On a
DG/UX cluster, a physical disk located on a shared bus will have
multiple common device specifications, one for each node. For this
reason, a cluster-wide device name is provided for each physical disk
residing on a shared bus. Cluster-wide device names replace the node
specific information within the common device specification (e.g. the
name and number of controller) with the shared_bus(shared bus number)
component (e.g. "sd(shared_bus(0),0,0)"). Cluster-wide device names
are therefore consistent across all nodes. On a DG/UX cluster,
cluster-wide device names may be used in place of the common device
specification. Furthermore, they are used by admpdisk in listings by
default (see the list operation).
Cluster-wide device names are generated and interpreted based on
information in the Membership Manager database; see Managing a DG/UX
Cluster.
Physical Disk States
Physical disks can be categorized as follows:
State Description
------------------------------------------------------------------
Not Does not appear on listings of physical disks.
configured. Does not have an entry in /dev/pdsk. Cannot be
initialized, registered, read or written. All
that can be done to such a disk is to configure
it.
Configured, Appears in listings of physical disks, has an
but not owned. entry in /dev/pdsk. Cannot be initialized,
registered (except with the -f option), read or
written. Cannot determine if it is initialized
or not.
Configured and Appears in listings of physical disks, has an
owned, but not entry in /dev/pdsk. Can be read or written
initialized. directly, verified, or initialized. Usable only
by special-purpose applications that manage
their own disk resources. Has no tables of
virtual disks or logical disks, no bad-block
mapping. Cannot be registered.
Configured and Has system areas, but they cannot be used
initialized in (logical disks cannot be used or manipulated).
logical disk Can be re-initialized, read or written directly,
format, but verified, converted to virtual disk format, or
not registered in compatibility mode.
registered.
Configured, Has partitions, but they cannot be used (virtual
initialized in disks cannot be used or manipulated). Can be
logical disk re-initialized or verified read or written
format, directly, possibly converted back to logical
converted to disk format or registered.
virtual disk
format, but
not
registered.
Configured and Has partitions, but they cannot be used (virtual
initialized in disks cannot be used or manipulated). Can be
virtual disk re-initialized, read or written directly,
format, but verified, or registered.
not
registered.
Configured, Has partitions, but they cannot be used (virtual
initialized in disks cannot be used or manipulated). Can be
virtual disk re-initialized, read or written directly, or
format and registered. Cannot be verified.
clustered, but
not
registered.
Configured, Normal operating condition. Virtual disks can
initialized, be manipulated and used. Can be read, but
and cannot be written to directly (only virtual
registered. disks can be written to). Can have a new
bootstrap or bad-block mapping facilities
installed. Cannot be verified.
Configured, Clustered operating condition. Virtual disks
initialized, can be manipulated and used (with restrictions
registered, stated above). Can be read, but cannot be
and clustered. written to directly (only virtual disks can be
written to). Can have a new bootstrap or bad-
block mapping facilities installed. Cannot be
verified.
Normally, physical disks are configured when the kernel is booted, so
there is no need to configure them dynamically. In addition, when
the kernel is booted, those physical disks that are in virtual disk
format are automatically registered if possible. Disks that are in
logical disk format can be registered in compatibility mode, but only
by an invocation of admpdisk; the kernel will not do it
spontaneously.
PC Partitioned Disks
PC partitioned physical disks are physical disks that contain PC (or
DOS) style disk partitions. Generally, PC partitioned disks are only
applicable to the Intel platform, although a DOS file system on a PC
partitioned disk can be accessed by the 88k platform (see mount(1M)).
Currently, DG/UX file systems on PC partitioned disks cannot be
access on the 88K platform.
PC partitions are not to be confused with virtual disk partitions
(related to the Virtual Disk Manager; see vdm(7)). PC partitions
occupy a contiguous area of a physical disk. They are an artifact of
Intel based personal computers. Virtual disk partitions, on the
other hand, are DG/UX system abstractions and not related to the
hardware. To avoid confusion, the term PC partition is used when
referring the PC style disk partitions. Unused disk areas between PC
partitions are referred to as reserved areas.
All physical disks initialized on the Intel platform are formatted to
hold PC partitions. A DGUX_vdm PC partition is created and used by
the DG/UX system to hold and store virtual disks and the virtual disk
information tables. PC partition information is stored in the
Partition Table. This table is contained within the Master Boot
Block which is stored in the first sector of the physical disk.
There are only four entries in the Partition Table, which means there
can be at most four PC partitions defined for a physical disk. Each
entry holds the attributes for a PC partition which includes the PC
partition type and a boot flag.
The PC partition type or partition_id is an 8 bit value used to
identify the operating system/data in the PC partition. There are
some well known values for common PC based operating systems (e.g. 1
for DOS version 2.x). The DG/UX operating system also uses a special
value to denote a DG/UX PC partition. For any PC partitioned
physical disk, there can be at most one PC partition of any given
partition_id. Either the well known name (e.g. DOS_3.x), or the
hexadecimal value preceded by '0x' (e.g. 0x04) may be used as a
partition_id. The following is a table of known names and their hex
value accepted by admpdisk.
Name Hex Name Hex
--------------------+---------------------
DOS2.x 0x01 | XENIX_root 0x02
XENIX_usr 0x03 | DOS3.x 0x04
DOS_ext 0x05 | DOS4.x 0x06
Windows_NT 0x07 | AIX 0x08
AIX_bootable 0x09 | OS2_bootable 0x0a
Venix_286 0x40 | Microport 0x52
DOS_data 0x56 | Sys_V 0x63
Novell 0x64 | PCIX 0x75
MINIX_old 0x80 | Linux 0x81
Linux_swap 0x82 | Linux_native 0x83
Amoeba 0x93 | Amoeba_bbt 0x94
BSDI 0xb7 | BSDI_swap 0xb8
Syrinx 0xc7 | CPM 0xdb
DGUX_vdm 0xdf | DOS_access 0xe1
DOS_RO 0xe3 | DOS_2nd 0xf2
XENIX_bbt 0xff |
Admpdisk will allocate PC partitions for other operating systems, but
care should be taken to ensure the partition_id is the correct value.
Associated with each PC partition is a boot flag which indicates
whether the PC partition is the bootable partition. At most one is
allowed to be set at any time. This PC partition is said to be the
boot partition, and is the PC partition booted at system startup.
Care should be taken when setting the boot partition. Depending on
the operating system, additional preparation may be necessary in
order to boot correctly. For example, the DG/UX system will not boot
until it's bootstraps are installed (see the install operation).
Boot flags can be set for PC partitions on physical disks other than
the primary physical disk (the physical disk booted at system
startup), but they generally serve no purpose.
A PC partitioned physical disk must be initialized before it can be
used for creating and manipulating virtual disks. Additionally, a
DGUX_vdm PC partition must exist on the PC partitioned disk. Both
steps can be accomplished with the initialize operation. Note that
simply creating a DGUX_vdm PC partition via the partition operation
is not sufficient; the physical disk must have virtual disk
information tables installed. On the Intel platform, admpdisk
initializes all physical disks into PC partitioned disks, that is, a
Master Boot Block is installed (if one doesn't exist) as part of the
initialization. See the initialize operation for more details.
When PC partitioned physical disks are registered, temporary virtual
disk partitions are created that overlay the non-DG/UX PC partitions,
reserved areas, and the master boot block. This ensures those areas
of the disk are not accidentally allocated to permanent virtual disks
for use by the DG/UX operating system.
Virtual disks that overlay non-DG/UX PC partitions have names based
on the partition_id along with the prefix PC_Partition_. For
example, a DOS4.x PC partition would be overlaid with a virtual disk
with the name PC_Partition_DOS4.x. These virtual disks are
automatically exported as well, meaning they have entries in /dev/dsk
and /dev/rdsk. These special device interfaces provide access to
those non-DG/UX PC partitions. For example, a DOS4.x PC partition
can be accessed by mounting the temporary virtual disk
PC_Partition_DOS4.x which overlays it as a DOS file system. See the
mount(1M) command for details on mounting DOS file systems.
Default Virtual Disks
On each physical disk that is in virtual disk format, except those
that are clustered, a default root virtual disk and a default swap
virtual disk may be specified.
If a default root is specified, then when the system is booted,
unless the default is overridden, the /dgux kernel image will be
retrieved from that virtual disk. The bootstrap requires that the
virtual disk from which it obtains the /dgux image be either a
partition virtual disk or an aggregation virtual disk whose children
are all partition virtual disks on the same physical disk. However,
admpdisk will not prevent you from setting the default root to a
virtual disk that does not satisfy this requirement. In addition,
when the kernel is booted, it determines if the physical disk from
whence it was booted contains a default root virtual disk
specification. If it does, then that virtual disk is used as the
root file system by the kernel.
Similarly, when the kernel is booted, it determines if the physical
disk from whence it was booted contains a default swap virtual disk
specification. If it does, then that virtual disk is used as the
swap device. The swap virtual disk may be of any type, and be
located on any physical disk that will be configured and registered
when the kernel is booted. However, if you want to use space on
multiple physical disks for swapping, it is generally better to
specify the areas separately, rather than collecting them together
with an aggregation virtual disk. See admswap(1M).
On a DG/UX cluster, the root file system as well as the swap area for
multiple nodes may reside on the same physical disk (a clustered
physical disk). Setting the default root and swap virtual disks on
such a physical disk would cause those nodes to try and mount the
same root file system and use the same swap device at system startup.
For this reason, default virtual disks cannot be set on clustered
disks, instead the Membership Manager should be used to specify the
root and swap virtual disks for each node.
Confirmation
By default, admpdisk asks for confirmation before performing any
potentially destructive operation. In some contexts, such as
invoking admpdisk from an idl(4) script, or from a shell script being
run in the background, such requests for confirmation may be
inappropriate. Requests for confirmation can be broken down into two
categories: "standard" ones that are predictable, such as with
creating a virtual disk table on a physical disk, and "exceptional"
ones that may or may not be issued, depending upon factors that are
determined dynamically. An example of the latter is when attempting
to install a bootstrap on a physical disk that has no label. To
manage this issue, the following options are provided:
-q Quiet. Standard confirmation requests are suppressed.
Admpdisk behaves as if the request were generated, and the
user gave confirmation. Exceptional confirmation requests
are still generated. This option is appropriate when
admpdisk invoked from an idl(4) script, or by a user who is
confident that the requested operation is correct.
-Q Very quiet. All requests for confirmation are suppressed,
including all those suppressed by the -q option. Admpdisk
behaves as if the request were generated, and the user gave
confirmation. This option is appropriate when admpdisk is
invoked from a script that will be run in the background,
so there is no way for a user to interact with it. See the
individual operation and option descriptions for the
exceptional confirmations that this option suppresses.
Both the -q and -Q options are legal with all operations, although
they will not have any effect on those operations that don't generate
requests for confirmation. This is to allow one to write shell and
idl(4) scripts that will continue to work correctly even if admpdisk
is changed in the future to have more confirmation queries.
OPERATIONS
admpdisk -o list [ -qQavprwLNP ] [ device_spec ... ]
Displays information about one or more disks. If no disks are
specified, all configured disks, including those that are not
registered, are listed. On a DG/UX cluster, physical disks are
listed using their cluster-wide device name (if they have one)
by default. The listing can be modified to list the disk device
name as known on the local node (see the -N option). By
default, for each registered disk, the list output includes:
the common device specification of the physical disk,
the state of the disk, as follows:
avail Available, the normal operating condition.
not ready Empty diskette or CD-ROM drive.
not owned Drive is on a shared SCSI bus with another node,
and the other node has control of this drive.
clustered Drive is enabled for concurrent access by
multiple nodes.
not avail Otherwise unavailable.
the disk's registration status:
n Not registered.
y Registered.
c Registered in compatibility mode.
the disk's format:
vdisks
Contains virtual disks; an initialized disk.
pcdisk
Contains PC partitions; an un-initialized disk, a DOS
file system or DOS formatted floppy.
ldisks
Contains logical disks.
fsys Contains a file system.
none Contains no known format.
its size in blocks, and
the number of free blocks on the disk.
If you do not have the necessary permissions, some of this
information cannot be obtained, and the state will always be
listed as not avail, and the format, total blocks, and free
blocks are listed as n/a.
For disks that are not registered, the output consists of the
disk's name, an indication that the disk is not registered, and
the disk's size.
The number of free blocks is shown as n/a for disks:
that are not writable, or
for which it is not possible to determine if whether or not
they are writable, or
that do not have virtual disk partitions but are in use.
When such disks are listed with the -p option, any free space is
tagged appropriately; for example <unwritable free space> or
<maybe unwritable free space>.
-v Verbose. This is the default output style.
-p Partitions. In addition to the one line described above, a
listing of the virtual disk partitions on the disk is
produced. This list of partitions includes:
the name of the partition virtual disk, including the
ID number if necessary to disambiguate it; or, if it
has no name, a description of the role that the
partition plays in an ancestor virtual disk.
the size (in blocks) of the partition, and
the block address of the partition.
-a All. Contiguous system partitions (virtual disk partitions
whose names starts with '.') are listed individually by
name, rather than being shown as a single
"<Various System Partitions>" entry. Specifying -a is the
same as specifying -pa.
-r Registered. Only registered disks are listed; disks
registered in compatibility mode are not included. If an
unregistered disk is specified on the command line along
with this option, it is treated as an error.
-w Writable. Only writable disks are listed. If an
unwritable disk is specified on the command line along with
this option, it is treated as an error. The combination
-rw results in listing only those disks that are both
registered and writable. If a disk that is either
unregistered or unwritable is specified on the command line
along with this combination of options, it is treated as an
error.
-L Labels. Not applicable to the Intel platform. Each disk's
label is displayed along with any other information.
-N Node private names. On a DG/UX cluster, listings are
generated using the cluster-wide device names (for disks
that have them) by default. This option forces the use of
the common device specifications, as known on the node
generating the list. This option has no effect on non-
cluster systems.
-P PC style partitions. Not applicable to the 88K platform.
In addition to any listing described above, a listing of
the disk's PC partitioning information is produced. This
listing includes:
the partition_id (known name or hexadecimal format) or
.Reserved,
the boot status of the PC partition, as follows:
Boot The boot partition.
Non-boot A non boot partition.
n/a Not applicable (reserved areas).
the PC partition or reserved area's starting block,
its size in blocks.
-q Quiet. Output is in a format appropriate for parsing by
other software: no headers, fields are separated by colons
instead of white space.
-Q Very quiet. Lists only the names of the physical disks,
one per line, with no header.
admpdisk -o install [ -q ] [ -Q ] [ -m map_size ]
[ -b bootstrap_path ] [ -l label_file ] device_spec ...
The install operation can be used to install a label (-l),
install bootstrap program(s) (first creating the partition(s) if
necessary) (-b), and establish software bad-block mapping
ability on the physical disk (including creating the necessary
partitions) (-m). If no option is specified, nothing is done.
The disk is automatically registered when installing the
bootstrap(s) or bad-block mapping.
-m map_size
Map_size specifies the number of blocks to set aside for
software mapping of bad blocks. If a size of 0 is
specified, an appropriate default size will be chosen.
-b bootstrap_path
The -b bootstrap_path option will establish virtual disk
partition(s) for the bootstrap program(s) on the disk (if
none currently exist), and install the contents of the
specified path.
On the 88K platform, the bootstrap_path refers to the
bootstrap file itself. The contents of this file are
installed into the bootstrap partition. In order for a
bootstrap program to be usable, there must be a label on
the physical disk. By default, if the physical disk has no
label and the -l option has not been specified, admpdisk
will ask the user if a SCSI label should be installed. If
the user agrees, the label and bootstrap are installed; if
the user declines, neither is installed. This confirmation
request can be suppressed with the -Q option. Note that if
the disk is not a SCSI disk, the -l option should be used
to specify the correct label. The standard DG/UX bootstrap
program for the 88K resides in /usr/stand/boot.aviion.
On the Intel platform, the bootstrap_path refers to a
directory that contains four bootstrap files. These files
must have the names: boot2, boot3, boot4, and boot5. In
addition to installing the bootstrap programs, this command
also sets the DGUX_vdm PC partition as the boot partition.
The standard DG/UX bootstrap programs for the Intel
platform reside in the /usr/stand/boot.pc directory.
-l label_file
This option is not applicable to the Intel platform. On
applicable platforms, this option causes the disk label to
be rewritten according to the contents of the label_file.
Standard DG/UX label files reside in the
/usr/etc/sysadm/pdisk_labels directory.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm if a SCSI
label should be installed, when there is no label and the
user is requesting a bootstrap be installed.
admpdisk -o initialize [ -q ] [ -Q ] [ -V [ -n vdit_size ] ] [ -m
map_size ] [ -b bootstrap_path ] [ -l label_file ] device_spec
...
The initialize operation performs all functions listed in the
install operation; see the install operation for description of
common options. Additionally, it can install virtual disk
layout tables (-V), effectively destroying the contents of the
physical disk. The install operation is therefore a safer way
to install features such as software bad block mapping without
running any risk of accidentally wiping out the virtual disk
layout tables. If no option is specified, nothing is done.
When creating new virtual disk layout tables, the disk must not
be registered. On a DG/UX cluster, the disk must not be
registered by any other node either.
There is no way to initialize a disk into logical disk format.
On the Intel platform, physical disks are initialized into PC
partitioned disks. An initialized PC partitioned physical disk
will have a DGUX_vdm PC partition with virtual disk information
tables. If either the Partition Table or a DGUX_vdm PC
partition do not exist, admpdisk will install them.
Specifically, if the physical disk does not have a Partition
Table, a new one is installed and the entire physical disk is
allocated to a new DGUX_vdm PC partition. If the physical disk
already has a Partition Table, but not a DGUX_vdm PC partition,
then a DGUX_vdm PC partition is created from the largest
reserved area. If a DGUX_vdm PC partition already exists then
it is re-initialized and any existing data in the DGUX_vdm PC
partition is lost. This behavior provides a convenient one step
procedure for setting up a PC style physical disk for use in
creating virtual disks, at the same time protecting any existing
non DG/UX PC partitions that may reside on the physical disk.
To have more control over the size and location of the DGUX_vdm
PC partition, use the partition operation to allocate the
DGUX_vdm PC partition before initializing the physical disk.
If there is no room on the physical disk for a DGUX_vdm PC
partition, the operation fails. One or more existing PC
partitions will need to be deallocated via the departition
operation before the physical disk can be initialized.
-V Initialize virtual disk tables. This effectively destroys
any existing virtual disks that reside on the physical
disk(s) (but the actual data blocks of the virtual disks
may not be erased).
-n vdit_size
Create VDIT tables of specified block size. This option is
only valid with the -V option. The specified vdit_size
will be rounded up (if necessary) to the next multiple of
16. If this option is not specified, then the default VDIT
size is used which is based on the disk size. For physical
disks smaller than 1 gigabyte, the default VDIT size is 16
blocks. Physical disks of size 1 to 2 gigabytes have the
default size of 32 blocks, and so forth.
-q Quiet. Suppress asking the user to confirm installing new
VDITs.
-Q Very quiet. Suppress asking the user to confirm if a SCSI
label should be installed, when there is no label and the
user is requesting a bootstrap be installed.
admpdisk -o configure [ -q ] [ -Q ] device_spec ...
This operation is not supported in the Intel platform. On an
applicable platform, this operation will configure the specified
physical disk(s) in the kernel. Normally, disks are configured
statically when the kernel is built; such disks do not need to
be dynamically configured. In order for a disk to be
configured, the kernel must already contain the driver(s)
appropriate for that disk. Generally this means that one can
dynamically configure a device only if there is already another
device of the same type configured.
The configure and deconfigure operations are offered here for
historical compatibility and their use is discouraged. The
admdevice(1M) command is preferred over admpdisk(1M) for
configuring and deconfiguring. New scripts should use
admdevice. This operation will be removed in future releases of
the DG/UX system.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o deconfigure [ -q ] [ -Q ] device_spec ...
This operation is not supported on the Intel platform. On an
applicable platform, the operation will cause the specified
physical disk(s) to be deconfigured. To be deconfigured, a disk
must not be registered.
This operation is offered for historical compatibility and it's
use is discouraged. This operation will be removed in future
releases of the DG/UX system.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o convert [ -q ] [ -Q ] [ -r ] [ -f | -n ] device_spec ...
This operation is not supported on the Intel platform. On an
applicable platform, this operation will convert the specified
physical disk(s) listed from logical disk format to virtual disk
format (or vice versa, with the -r option). Only those physical
disks that were ever in logical disk format can be converted.
Stated another way, physical disks that have always contained
virtual disks (always been in virtual disk format) cannot be
converted into a logical disk format. For each logical disk, a
corresponding virtual disk (either a partition or an aggregation
of partitions) is created. For each logical disk-style software
mirror, a mirror virtual disk is created. Caches that used
logical disks cannot be converted. They must be deleted before
the physical disk is converted.
In situations where a logical disk or software mirror spans
multiple physical disks, then all the physical disks should be
converted at once, so that the relationship between the pieces
of the logical disk, or between the images of the mirror, can be
maintained.
By default, if the set of physical disks being converted
includes some but not all pieces of a logical disk (or an
aggregation but not all its children during a reverse
conversion), an error message is printed and the conversion is
terminated before the physical disks are modified. If a mirror
is found to have fewer than three images, a warning messages is
printed, but the conversion proceeds. This behavior can be
modified with the -f and -n options.
-r Reverse. The conversion is done in the reverse direction,
i.e. from virtual disk format to logical disk format. The
hierarchy of virtual disks on the physical disk(s) must be
compatible with what can be achieved using logical disks.
This includes the physical virtual disk on each physical
disk, a layer of partition virtual disks above that, and a
layer of aggregation virtual disks above that.
-f Forceful. The conversion proceeds even if there are
missing logical disk pieces (or missing children of an
aggregation in a reverse conversion).
-n No-write. The physical disks are not actually converted.
This is useful for determining if the set of physical disks
includes any incomplete logical disks (or aggregations).
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o register [ -q ] [ -Q ] [ -f ] [ -c | -C ] device_spec ...
Registers the specified disks(s). If no disks are specified on
the command line, all unregistered disks that can be registered
are registered. If the -C option is used, then disks will be
registered in compatibility mode, if necessary. During system
boot, physical disks in virtual disk format are normally
automatically registered.
-f Force. Used with physical disks that are owned by another
system; -f wrests ownership of the physical disk away from
the other system. This is normally used only when the
other system has crashed, and is normally used only by the
failover software (see admfailoverdisk(1M)).
In order to use the failover functionality, you must have
either the Failover package or the DG/UX Cluster Software
product installed.
-c Compatibility mode. This option is not supported on the
Intel platform. Allows registration of physical disks that
are formatted for logical disks, as described above. If a
logical disk spans more than one physical disk, then all
the physical disks involved must be registered
simultaneously, with the -c (or -C) option. Any logical
disk that is not fully present (all pieces accounted for)
on the physical disks being registered at one time will not
be represented by a virtual disk.
-C Optional compatibility mode. This option is allowed on the
Intel platform, but serves no purpose. Each physical disk
to be registered is registered normally (not in
compatibility mode) if possible (i.e. if it is formatted
for virtual disks), otherwise it is registered in
compatibility mode. If two physical disks are registered
with the -C option, and one is registered in compatibility
mode and the other not, the disks are considered to have
been registered separately, for the purposes of joining up
pieces of logical disk that span the two physical disks.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o deregister [ -q ] [ -Q ] device_spec ...
Deregisters the specified disks(s). At least one disk name must
be specified on the command line. A physical disk cannot be
deregistered if it contains a piece of a virtual disk that is
open (open by an application, mounted as a file system, being
swapped upon, or is the child of any virtual disk that is any of
these things).
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o cluster [ -q ] [ -Q ] device_spec ...
This operation is activated only after installing the Cluster
package. Enables concurrent access for the specified disk(s) by
all nodes within a DG/UX cluster. At least one disk name must
be specified on the command line. Where virtual disks span
physical disks, all related physical disks must be specified.
For example, if an aggregation type virtual disk spans two
physical disks, then both physical disks must be specified. The
physical disk(s) must be registered on the node this operation
is being performed. Once clustered, the disk(s) may be
registered by other nodes. This operation does not register the
disk(s) on other nodes.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o uncluster [ -q ] [ -Q ] device_spec ...
This operation is activated only after installing the Cluster
package. Disables concurrent access for the specified disk(s)
by all nodes within a DG/UX cluster. At least one disk name
must be specified on the command line. Where virtual disks span
physical disks, all related physical disks must be specified.
For example, if an aggregation type virtual disk spans two
physical disks, then both physical disks must be specified. The
physical disk(s) must be registered on the node this operation
is being performed. The physical disk(s) must be deregistered
by all other nodes.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o partition [ -q ] [ -Q ] -i partition_id [ -b block_count
] [ -s starting_block ] [ -B ] [ -c ] device_spec ...
This operation is not supported on the 88K platform. Allocates
physical disk space for a new PC partition. The partition
operation can be used to install a new Partition Table (master
boot block), allocate space for a new PC partition, set the boot
flag, and clean the space of a new PC partition. The physical
disk must not be registered.
If the physical disk does not have a Partition Table, then one
is installed, and space allocated for the PC partition (this
will destroy any existing data). Otherwise, an attempt is made
to allocated space from existing reserved areas.
Space for PC partitions is allocated based on the -b and -s
options. If both are given, the designated space (if available)
is allocated. If only a size (-b) is given, then space is
allocated from the first reserved area large enough to hold it.
If only the starting block (-s) is given, then the reserved area
starting at the designated block is allocated. If neither
option is supplied, then the largest reserved area is allocated.
Both the first and last block of a PC partition must be aligned
on a track boundary. If either the starting block or size in
blocks is supplied by the user, admpdisk checks for track
alignment and if necessary modifies either or both values just
enough to align with the next track boundary. If the user
supplies a size, the alignment is performed such that the PC
partition is at least the size the user requested. The user is
informed when supplied values are changed.
Checks are performed to make sure PC partitions do not overlap
and that multiple PC partitions of the same partition_id are not
created.
Modifying the size and location, that is, expanding or shrinking
an existing PC partition is not supported.
-i partition_id
The partition id of the PC partition to allocate.
-c Clean the allocated PC partition disk area. This option
cleans enough of the disk area to ensure that any existing
metadata will not be misinterpreted later and may not erase
all existing data.
-B Make the allocated PC partition the bootable partition.
-b block_count
The size in blocks to allocate to the PC partition.
-s starting_block
The starting block of the PC partition to allocate.
-q Quiet. Suppress asking user to confirm partitioning
device_spec.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o departition [ -q ] [ -Q ] -i partition_id [ -c ]
device_spec ...
This operation is not supported on the 88K platform.
Deallocates physical disk space previously partitioned to
partition_id. If partition_id is the bootable partition, then
after the departition operation, there is no bootable PC
partition. The physical disk must not be registered.
-i partition_id
The partition id of the PC partition to deallocate.
-c Clean the deallocated PC partition disk area. This option
cleans enough of the disk area to ensure that any existing
meta data will not be misinterpreted later and may not
erase all existing data.
-q Quiet. Suppress asking user to confirm departitioning
device_spec.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o set_boot_partition [ -q ] [ -Q ] -i partition_id
device_spec
This operation is not supported on the 88K platform. Sets the
PC partition that will boot on system startup. A physical disk
can be set to have no bootable PC partition by specifying a
partition id of "". Useful only for the primary physical disk.
-i partition_id
The partition id of the PC partition to make bootable or ""
to have no bootable PC partition.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
admpdisk -o copy [ -q ] [ -Q ] -s source -d destination
Copies the contents of physical disk source to physical disk
destination. The source disk need not be registered. The
destination physical disk must not be registered.
If the source disk is in virtual disk format, then the system
data is copied to the destination disk and all of the virtual
disk partitions are copied. This provides for bad block mapping
when reading the source. When copying a PC partitioned disk
that doesn't contain virtual disks, only the PC partitions are
copied and not the reserved (unused) areas of the physical disk.
If the source device is any other format or raw data, it is
copied directly to the destination device. In the latter case,
no mapping of bad blocks is done when reading the source.
The size of the destination must be greater than or equal to the
size of the source.
-s source
Source physical disk.
-d destination
Destination physical disk.
-q Quiet. Suppress asking user to confirm copying to
destination.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o get_defaults [ -q ] [ -Q ] device_spec
The default root and swap virtual disk specifications stored on
the specified physical disk are listed.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
admpdisk -o set_defaults [ -q ] [ -Q ] [ -r root_virtual_disk ]
[ -s swap_virtual_disk ] device_spec
The specified root_virtual_disk and/or swap_virtual_disk are
recorded on the physical disk. At least one of the virtual
disks must be specified. To make the physical disk have no
default disk of either type, specify a virtual disk name of "".
This operation is not allowed on clustered physical disks. This
would cause multiple nodes within a cluster to boot using the
same root file system and paging device. On cluster nodes, the
default root file system and paging device may be set via the
Membership Manager database.
-r Default root virtual disk. To arrange to have no default
root virtual disk, specify -r "".
-s Default swap virtual disk. To arrange to have no default
swap virtual disk, specify -s "".
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
admpdisk -o repair_vdit [ -q ] [ -Q ] device_spec
On the specified physical disk, the damaged copy of the Virtual
Disk Information Table is restored from the undamaged copy. If
possible, the physical disk is deregistered and reregistered, to
allow full use of the disk. If the deregistration or
reregistration fails, the disk will remain in a mode wherein
modifications to virtual disks (creation, removal, etc.) are
forbidden.
This operation is not allowed on clustered physical disks under
normal operating conditions. To repair a VDIT on a clustered
disk. The cluster must be taken down. One node must be booted
using standalone sysadm in cluster administrative mode. The
repair_vdit operation can then be used to repair the damaged
VDIT. Once the VDIT is repaired, the cluster can be brought
back up.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
admpdisk -o list_mapped_blocks [ -q ] [ -Q ] device_spec ...
The block numbers of those blocks that have been the object of a
map_block operation (or an equivalent mapping operation
performed by the kernel) are listed. The status field for each
block will be one of the following values:
mapped
The bad block has been mapped to a new block. All I/O is
being redirected to this new block.
unmapped
The kernel has detected an error upon attempting to read
this block. Although the original block has a remap block
associated with it, the contents of the remap block are
undetermined. Until a write is performed to the new block,
reads directed to the original block will fail.
force
A user has performed a map-block operation upon this block.
Although the original block has a remap block associated
with it, the contents of the remap block are undetermined.
Until a write is performed to the new block, reads directed
to the original block will fail.
pseudo
An entry with this status corresponds to a block that does
not necessarily need remapping but whose contents are
undetermined. Reads to pseudo bad blocks will fail. The
first write to a pseudo bad block sets its contents and
deletes the corresponding remap table entry.
bad An entry with this status represents a block in the bad-
block map area itself that is unusable.
-q Quiet. Output is in a format appropriate for parsing by
other software: no headers, fields are separated by colons
instead of white space.
-Q Very quiet. Suppresses asking the user to confirm
anything. Currently there are none.
admpdisk -o verify [ -f ] [ -q ] [ -Q ] { -B blockno_list } ...
device_spec ...
Performs surface analysis on the disk. This is generally not
required for AViiON disk drives.
You must manually specify which blocks to verify with the -B
option. The disk must not be registered. On a DG/UX cluster,
the disk must not be registered on any other node. Each block
is written and read, and any hard I/O errors are reported. Soft
I/O errors are reported only to the system console. The verify
operation will not result in any blocks being automatically
tagged for software bad-block remapping. If you want them to be
mapped, you must use the map operation explicitly.
By default, three passes are made over the appropriate block(s)
of the disk, writing and reading three different bit patterns.
You may use the -f (fast) option to make admpdisk use only one
bit pattern.
-B blockno_list
Block numbers. Multiple block numbers may be specified by
using multiple -B options, or by using one -B option with a
comma-separated list of block numbers. Ranges of block
numbers can be expressed using dashes, as in -B 2500-2510.
-f Fast. Only one pass is performed, using one bit pattern,
instead of three.
-q Quiet. Suppress asking user to confirm verifying
device_spec.
-Q Very quiet. Suppress asking the user to confirm anything.
admpdisk -o map_block [ -q ] [ -Q ] { -B blockno_list } ...
device_spec
The block(s) specified with the -B option are marked as being
unusable, and alternative blocks on the physical disk are
substituted for them (i.e. they are put into the force state).
Nothing is done to recover data from the defective block(s).
Blocks that are part of any of the partitions that are created
by the initialize or install operations cannot be mapped. These
partitions include the Virtual Disk Information Table, the label
(block 0 on the 88K platform), the bootstrap, master boot block
(block 0 on the Intel platform), and the bad block map area
itself.
-B blockno_list
Block numbers. Multiple block numbers may be specified by
using multiple -B options, or by using one -B option with a
comma-separated list of block numbers. Ranges of block
numbers can be expressed using dashes, as in -B 2500-2510.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
admpdisk -o unmap_block [ -q ] [ -Q ] { -B blockno_list } ...
device_spec
The block(s) specified with the -B option are marked as being
usable, and the substitute block(s) that had been allocated to
them are released.
-B blockno_list
Block numbers. Multiple block numbers may be specified by
using multiple -B options, or by using one -B option with a
comma-separated list of block numbers. Ranges of block
numbers can be expressed using dashes, as in -B 2500-2510.
-q Quiet. Suppress any standard requests for confirmation.
Currently there are none.
-Q Very quiet. Suppresses asking the user to confirm
anything.
FILES
/etc/pdsk/* block special physical disk devices
/etc/rpdsk/* character special physical disk devices
DIAGNOSTICS
Exit Codes
0 The operation was successful.
1 The operation was unsuccessful.
2 The operation failed due to access restrictions.
3 There was an error in the command line.
SEE ALSO
admvdisk(1M), admdevice(1M), appropriate_privilege(5),
cap_defaults(5), mount(1M), vdm(7), vdmphys(7), vdmpart(7),
vdmaggr(7), vdmremap(7).
NOTES
Physical disk devices should be configured and deconfigured using the
admdevice(1M) command.
You must have appropriate privilege to register and deregister
physical disks. For systems supporting the DG/UX Capability Option,
appropriate privilege is defined as having one or more specific
capabilities enabled in the effective capability set of the user.
See cap_defaults(5) for the default capabilities for this command.
On systems without the DG/UX Capability Option, appropriate privilege
means that your process has an effective UID of root. See the
appropriate_privilege.5 man page for more information.
Licensed material--property of copyright holder(s)