| Logical
Volumes |
Physical
Volumes |
|
|
|
| Volume
Groups |
Other
Utilities |
|
|
- bootinfo
- lsps
- list paging space info
- savebase
- reads the base customized information from the ODM and
restores it to the boot device
- restbase
- reads the base customized information from the boot
image and restores it in the ODM
- sysdumpdev
- schedtune
- detects when the system is thrashing and suspends active
processes
- getlvodm
- determine whether the ODM or VGDA has the correct copy
- synclvodm
- read the VGDA from the Physcial Volume specified and
update the ODM
|
|
Useful
Information |
|
|
|
top
of page
| Examples |
What
it means |
| PHYSICAL
PARTITION (PP) |
Smallest
unit a PV is divided into (4 MB partition size) |
| LOGICAL
PARITITION (LP) |
One
or more PPs. LP represents a mirrored copy of a PP. Up to
two copies of a PP can be mirrored resulting in a LP count
of three (2 mirrors plus original). |
| LOGICAL
VOLUME (LV) |
One
or more PPs. A file system resides on top of an LV. Only one
LV is mapped to a file system. A LV can't span across a VG.
Up to 255 LVs in a VG |
| VOLUME
GROUP (VG) |
One
or more PVs. A collection of PVs that users view as a single
oversized PV. A VG can consist of any mixture of physical
disk types (size=320,355,400,670,800,857 MB), though performance
is most consistent if devices of the same size are used in
a single VG. Up to 32 VGs per system. |
| PHYSICAL
VOLUME (PV) |
One
or more LVs. Represents a hard disk (hdisk0). |
| AREA
(VGDA) |
Information about all the LVs and PVs within a VG. First 64K
of a PV is reserved for this area - defined in <sys/bootrecord.h>.
The VGDA consists of
- BOOTRECORD:
- first 512 bytes. Allows the Read Only System (ROS) to
boot system
- BAD
BLK DIRECTORY - found in <sys/bddir.h>
- LVM
RECORD - found in <lvmrec.h>
|
| AREA
(VGSA) |
Informations about which PPs are stale and which PVs are missing
within a VG. The LVM and SCSI driver reserves somewhere between
7-10% of the available disk space for LVM maps, etc. |
Logical
Volume Set-up
All system
LVs (hd1..hd8, hd9var) should reside in the VG named rootvg,
under one PV if possible. This will allow complete re-installation
of the system from your 'mksysb' tape without affecting the
application data that resides on your other VGs.
There
is no difference in response time between a single or multiple
VGs. When an LV is accessed
- The
ODM database (/etc/objrepos/*) is searched to determine
which VG the LV belongs to.
- Then
the VGDA for that VG is read to determine the physical placement
of the LV on that PV and ultimately the physical track and
sector where the data resides.
A few notes
about Mirroring
Mirrored
LVs that generate lots of write I/O calls, will cause a disk
performance penalty (such as paging LVs). For LVs that encounter
heavy read I/O calls, disk performance is increased.
Since the LVM (logical volume manager) driver keeps track
of the location of each disk head, the disk arm closest to
the data being requested will be issued the read request.
Further, mirroring can only be performed within a single VG.
NFS mounted file systems cannot be mirrored.
top
of page
When a system
is re-installed, the disk drives may not be named in the same
order as they originally appeared. If the
system halts with the message 'performing Auto varyon of Volume
Groups' on the console, perform these steps:
- Press
CTRL-C to continue and login as
root
- Export
ALL non-root volume groups export
<VGName>
- Shutdown
and reboot the system shutdown
-Fr
- Re-import
non-root volume groups importvg
-y <VGName> <PVName>
top
of page
- Backup
all filesystems found on the failing PV.
- lspv
-l <PV> (lspv -l hdisk2) To determine
which filesystem(s) are found on the PV in question.
- Find out
how the LVs are laid-out on the PV so you will know how to re-create
them when the time comes.
- lslv
-m <LV> (lslv -m oracle) You will use
the output of the lslv command to serve as a template for creating
a map file for this LV later on.
- Unmount
all filesystems on that PV. umount
<FILESYSTEM_NAME> to unmount each filesystem
from the PV in question.
- Remove
all LVs found on that PV. rmlv
<LV> (rmlv /oracle)
- Remove
the questionable PV from the system. reducevg
<VG> <PV>
- Remove
the PV entry from the ODM database. rmdev
-l <PV_NAME> -d (rmdev -l hdisk2 -d)
- Shutdown
the system: Shutdown -F
- Remove
the bad PV and install the new PV
- Add the
new PV to the VG in question. extendvg
<VG> <PV> (eg., extendvg datavg
hdisk2)
- Re-create
the LVs removed from the OLD PV to the NEW PV.
mklv -y<LV> -m<MAP_FILE>
<VG> <PP_NUM> <PV> (mklv -y
oracle -m oracle.map oraclevg 200 hdisk2)
The map file is assembled from the output generated from the
lslv -m command in step 2 above. Do this for each
LV that existed on the removed PV.
- Re-size
the filesystems on the new PV. mkfs
/dev/<LV> (mkfs /dev/oracle) Do this for
each file system that existed on the removed PV.
- Perform
a filesystem check before mounting it.
fsck -f /dev/<LV> (fsck -f /dev/oracle)
- Mount
all filesystems on that PV. mount
<FILESYSTEM_NAME> (mount /oracle)
- Now restore
the data you backed up
top
of page
- mklv
- mklvcopy
- synvg
-l <LV>
top
of page
As long as
all your doing is moving a PV to another SCSI adapter and not
placing that PV in another VG, then just move the PV to the other
SCSI adapter and reboot. When the machine comes back up and finds
that the disk is no longer located in its previous slot, it finds
the exact PVID of the disk on the other adapter and assumes the
disk was moved. It then changes the ODM accordingly, and your
back in business again.
top
of page
Each hard
drive is a potential boot device. The bosboot command creates
a bootable image in the BLV (boot logical volume), which is used
to boot AIX. The first block (sector) on the disk is called the
boot block or IPL record. In addition, NVRAM contains a list of
boot devices which can be specified by the bootlist command. The
boot device can be changed by using the bosboot and bootlist commands.
The format for these commands follows:
bootlist
-m normal hdisk0 for normal operations
bootlist -m service fd0 rmt0 hdisk0 for service operations
bosboot -u -d /dev/hdisk0
bootable image in BLV on hdisk0
The bosboot
command puts a bootable image in the BLV that is used to boot
the system. Also, the bosboot command puts the physical sector
number of the beginning ofthe bootable image on this disk, into
the boot block of the disk. Since only one PSN (that of the primary
copy of the BLV) is stored, therefore all copies of the BLV must
reside on the SAME physical partitions of their respective devices.
An example
of a mirrored BLV with 3 copies follows:
blk XXX, where
XXX is the starting physical sector number in hex, within the
specified physical partition (PP) number.
| Copy
1 |
Copy
2 |
Copy
3 |
| hdisk0 |
hdisk1 |
hdisk2 |
| LP 1:
PP 1(blk 200 ) |
LP 1:
PP 6(blk C200) |
LP 1:
PP 4(blk 8200) |
| LP
2: pp 2(blk 2200) |
LP
2: PP 7(blk E200) |
LP
2: PP 5(blk A200) |
To use hdisk0
as the boot device, specify the following: bosboot
-a -u -d /dev/hdisk0
The IPL
record on hdisk0 indicates the boot image starts at PSN (physical
sector number) 200. Now, the system can be booted using drive
hdisk0.
To use hdisk1
as the boot device, issue the following: bosboot
-a -u -d /dev/hdisk1
Because the
bosboot program only looks for the PSN of the first copy, the
IPL record indicates the starting PSN for the boot image as 200
instead of the correct C200. Attempts to boot with hdisk1 as the
boot device will fail.
To mirror
the BLV and get around this problem, do the following. Insure
that all the copies occupy the same physical partitions on each
device. It is not important which partitions the BLV uses, but
all copies must use the same relative positions on the disk device.
So, the configuration should be:
| Copy
1 |
Copy
2 |
Copy
3 |
| hdisk0 |
hdisk1 |
hdisk2 |
| LP 1:
PP 10(blk 20200) |
LP 1:
PP 10(blk 20200) |
LP 1:
PP 10(blk 20200) |
| LP 2:
pp 11(blk 22200) |
LP 2:
PP 11(blk 22200) |
LP 2:
PP 11(blk 22200) |
To move individual
partitions around and keep them in sync, use the lmigratepp
command.
To find available
physical partitions on a disk, use lspv
-m hdisk? Take the output of this command and
choose two physical partition that are allocated/free on all the
target disks and use these partitions to create your BLV image
on multiple disk drives.
If your mirroring,
make sure that PTF U407433 is installed. This allows you to disable
the QUORUM feature. When one disk dies, the other disk will take
over without checking to see if the quorum is still meet. (chvg
-Qn rootvg)
When a write
is performed to a disk containing mirrored copies, all copies
are written simultaneously in parallel mode, and each is written
sequentially in sequential mode.
Should the
system crash while parallel writes are being performed to mirrored
copies of the data, inconsistencies may exist between the data
which was actually written to the different copies. To protect
against this, the Mirror Write Consistency Cache was developed
to write a record to the disk each time a mirrored write is in
progress, so that when the system is rebooted, a record will show
that possible inconsistencies may exist, and the data from the
first physical partition is rewritten to all other physical partition
copies. However, by enabling the Write Consistency Check, the
penalty you pay is having to do an extra read/write when doing
I/O. When this feature is disabled, if the system goes down because
of power failure or system crash, you will need to MANUALLY perform
a syncvg when the system is rebooted.
The jfslog
is used to keep a record of file system metadata (superblock,
inode, directories, etc) and also ensures the integrity of the
file system.
The impact
of losing the PV containing the jfs log will be quite serious.
All file systems using that log will become unavailable.
top
of page
| Examples |
What
it does |
| /usr/sbin/bootinfo
-b |
Displays
the boot PV device (hdisk0). The boot
PV does NOT always refer to hdisk0. The boot PV will
ALWAYS be the PV that contains the LV named hd5. The LV hd5
contains the boot logical volume (BLV), which contains the
information needed to boot the system into a single/multi-user
state |
| bootinfo
-a |
hdisk1
320 4 8 00-01-00-00 |
top
of page
Changes the
attributes for an LV
| Examples |
What
it does |
| chlv
-x 256 hd1 |
When
creating large LVs or extending an existing LV to over 512
MB (assuming PP SIZE=4) in size, the following error message
will be displayed: 516-787 extendlv:
Maximum allocation for logical volume h1 is 128.
To resolve this problem, perform the above command
where 256 represents the MAXIMUM number of logical partitions
that can be allocated for that LV. This command can be executed
while the file system (residing on top of the LV) is mounted. |
| chlv
-n informixlv lv00 |
Changes
the name of LV from lv00 to informixlv. If there is a filesystem
mounted on top of that LV, the file system must be unmounted
and the LV must be in a closed state for this command to work.
chlv -n <NEW LV> <OLD_LV> |
top
of page
Copy the contents
from one LV to a new or existing LV
| Examples |
What
it does |
| cplv
-e newroot hd4 |
Copies
the LV hd4 to an LV named newroot. If newroot doesn't exist,
it will be created. If newroot is smaller
than hd4, the extra PPs from hd4 won't be copied to the desintation
LV newroot |
top
of page
Change the
characteristics of a physical volume
| Examples |
What
it does |
| chpv
-a n hdisk2 |
Prohibits
the allocation of additional PPs on PV hdisk2 |
| chpv
-vr hdisk2 |
Temporarily
removes a PV from a VG (normally used for maintenance) This
command removes the VGDA and VGSA copies from the PV, thereby
affecting the number of copies required for a quorum. |
| chpv
-va hdisk2 |
Returns
an inactive PV back to the VG |
top
of page
| Examples |
What
it does |
| chvg
-Qn rootvg |
This
will turn quorum checking off (default is on). Afterwords,
the volume group must be varied off and back on again to cause
the change to take effect. In the case of rootvg, this means
a reboot. |
top
of page
Used to export
a VG from one system so that it can be imported by another. This
command will erase all data referencing the VG being exported
from the ODM database, but won't remove this information from
the VGDA (undefines the VG on the system). The information deleted
from the ODM but not the VGDA is the LV and VG entries.
To manually
transport a VG between systems, the normal process is to varyoff
and export the volume group on System A:
varyoffvg
VG
exportvg VG
Then move
the drives to System B followed by importing them and finally
varying them on:
importvg
-y VG PV
varyonvg VG
exportvg
vg2
importvg -y vg2 hdisk1 #hdisk1 is PV that belongs to VG
named vg2
varyonvg vg2
The above
steps can be used to correct the ODM when it is not in sync
with the VGDA
top
of page
Add a new
physical drive to a volume group
| Examples |
What
it does |
| extendvg
datavg hdisk3 |
Adds
the PV hdisk3 to VG datavg. This increases the size of the
VG by adding one or more PVs. |
top
of page
| Examples |
What
it does |
| getlvodm
-u rootvg |
Will
determine whether the ODM or VGDA has the correct copy of
the VGDA. If the above command returns the character 'y'
for the VG specified, then the ODM database is correct and
the VGDA is out-of-sync. To correct
the situation when the VGDA doesn't have a good copy, perform
the following steps:
-
importvg -y vg2 -f hdisk1
use force option
- varyonvg
-f vg2
use force option
- copy
data off drive
- reducevg
vg2 hdisk1
- rmdev
-l hdisk1 -d
- cfgmgr
- extendvg
vg2 hdisk1
- add
file systems
- restore
data previously backed off to tape
|
top
of page
Used to import
a VG from a system that exported it. This command will restore
the ODM database from information read from the VGDA. When a VG
is imported, /etc/filesystems will be updated with any entry points
needed for those LV's and mount points not currently defined.
top
of page
| Examples |
What
it does |
| ipl_varyon
-i |
Indicates which PV is your BOOT drive |
top
of page
| Examples |
What
it does |
| lqueryvg
-p hdisk0 -v |
List
the VG id in which the PV hdisk0 resides |
| lqueryvg
-p hdisk0 -L |
List all the LV ids/names in the VG where PV hdisk0 resides |
| lqueryvg
-p hdisk3 -P |
Lists
all the PV ids that reside in the VG where hdisk3 resides |
top
of page
List characteristics
about a logical volume
| Examples |
What
it does |
| lslv
hd3 |
Display
attributes of the LV hd3 |
| lslv
-l hd3 |
List
distribution of where LV hd3 resides on PV hdisk1 |
| lslv
-m hd3 |
List
distribution of PPs where LV hd3 resides on PV hdisk1 |
- MAX
Lps: If LV created is larger than 512 MB (128 * 4),
then this field needs to be upped by the following formula:
(LV size in megabytes) / PP size = MAX LP count 900 MB / 4 =
225 The command to change the LP count to 225 for an LV named
pick is: chlv -x 225 pick
- COPIES:
- value
is 1= original copy
- value
is 2= first mirrored copy
- value
is 3 = second mirrored copy
- STALE
PPs: If COPIES > 1 and STALE PPs > 0, means that
a mirrored LP is not available or current with other LPs.
- INTER-POLICY:
- If
set to MIN, an LV will only reside on 1 drive
- If
set to MAX, an LV can span multiple LVs. Distributes an
LV among more than 1 PV.
- INTRA-POLICY:
Has 3 values (edge, middle, center). When an LV is created,
it will be assigned 1 of the 3 allocation strategies listed
above.
- EFFICENCY:
Represents the efficency with which PPs are allocated based
on the 3 possible states of the intra-policy.
- RELOCATABLE
: If yes, then the 'reorgvg' command is allowed to move the
LV to a new position on the current PV or be placed on another
PV.
- SCHEDULING
POLICY: If set to PARALLEL, insures writes to mirrored
copies are performed to seperate PVs in parallel.
- WRITE-VERIFY:
If set to NO, will not perform a follow-up read to each write
for verification.
- MIRROR
WRITE CONSISTENCY: When enabled, suffer a 20% performance
penality. Use the syncvg -v <VG>
command to resync disk drives in a VG that loses a PV.
top
of page
List characteristics
of paging space(s).
PAGING
SPACE LOW
messages will be generated when 512 pages remain free in the pool
of free pages. Processes will be terminated when only 128 pages
of free memory are left.
AIX determines
which users have the most page space allocated to them and selects
those processes for termination. All real memory allocated to
a process will have a backing store of equal size (for every page
of real memory allocated, there will be a page of disk space from
paging space allocated)
Its
recommended that the first paging space (/dev/hd6) be larger,
since this one is brought on sooner than the rest, resulting in
being more full than the others.
Thrashing
should not be confused with the problem of low paging space. Low
paging space is the condition in which the amount of paging space
is insufficient. Thrashing is the condition in which the amount
of RAM is insufficient. Low paging space involves the consumption
of disk space; thrashing involves the consumption of RAM and disk
I/O.
Example:
lsps -a (Display attributes of all paging
spaces)
LV hd6 is
the default paging space. If more than one paging LV is defined,
hd6 will always have a higher percentage of utilization since
this is the first paging LV turned on at boot time. Once all the
other paging LVs have been swapped on, paging is allocated on
a round robin basis - four pages (pagesize is 4k ) at a time.
80% (MAXPERM)
of real memory is to be used by persistent storage. Persistent
storage is information that is not paged to the page space (/dev/hd6)
but rather is paged to the physical volume where that file resides.
top
of page
List charactertistics
of a physical volume
| Examples |
What
it does |
| lspv
hdisk0 |
Stale
partitions refers to mirroring. If the PV has no mirrored
LPs, then the value for this field is zero. |
| lspv
-l hdisk0 |
Display
distribution of what LVs reside on the PV named hdisk0 |
| lspv
-p hdisk0 |
Display
distribution of PPs for each LV that resides on the PV named
hdisk0 |
top
of page
List characteristics
about volume groups
| Examples |
What
it does |
| lsvg
rootvg |
Display
attributes for VG rootvg |
| lsvg
-p rootvg |
Display
PV distribution about VG rootvg |
| lsvg
-o |
Lists all active VGs in the system |
top
of page
Moves one
or more LVs to one or more PVs. If '/dev/hd5'
is moved to another drive, a spcial step is required, else the
system will not boot the next time it's rebooted.
| Examples |
What
it does |
| migratepv
hdisk0 hdisk1 |
Moves
all LVs from hdisk0 to hdisk1 |
| migratepv
-l hd1 hdisk2 hdisk1 |
Copies
all PPs for LV hd1 from hdisk2 and places them on a PV named
hdisk1 |
top
of page
Creates a
logical volume on a physical volume
| Examples |
What
it does |
1)
mklv -y hd7 -t sysdump -a e rootvg 2
hdisk0
2) sysdumpdev -P -p /dev/hd7 |
The
first command will create a LV dump device named hd7 that
consists of 2 PPs located on the edge of PV hdisk0. The second
command will assign the system dump device to LV /dev/hd7. |
1)
mklv -y hd5 -t boot -a e rootvg 2 hdisk2
OR
1) migratepv -l hd5 hdisk0 hdisk2
2) bosboot -a -l /dev/hd5 -d /dev/hdisk2
3) bootlist -m normal hdisk2 |
Creates
and updates a new boot logical volume (hd5) on PV hdisk1.
When you move the /blv (boot) file system,
you MUST change the disk from which the system tries to boot
from to NORMAL mode. |
top
of page
Makes a mirrored
copy of an LV. Note that this command will
allocate PPs for the next copy, but the data within is not updated.
This must be performed by the syncvg
command.
| Examples |
What
it does |
1)
mklvcopy hd1 2 hdisk1
2) mklvcopy hd2 2 hdisk1
3) mklvcopy hd3 2 hdisk1
4) mklvcopy hd4 2 hdisk1
5) mklvcopy hd5 2 hdisk1
6) mklvcopy hd6 2 hdisk1
7) mklvcopy hd7 2 hdisk1
8) mklvcopy hd8 2 hdisk1
9) syncvg -v rootvg |
Will
mirror the operating system so that the system may be booted
from either disk in the case of a disk drive failure. The
syncvg command will insure that all LVs just copied will
be in synchronized with each other.
- The
third parameter ('2') means make a copy of the original
LV (hd?) on the PV named hdisk1.
- If
the third parameter was a '3', then each LV would have
3 copies total - 2 mirrored copies and the original.
|
1)
mklvcopy -m lv00.map lv00 2
2) syncvg -l lv00 |
When
creating the LV named lv00, use the map file named lv00.map.
Using the syncvg command will update the mirror copy. |
top
of page
Reads LV data
from the command line and writes it to appropriate ODM (Object
Data Manager) class fields.
| Examples |
What
it does |
| putlvodm
-K `getlvodm -v rootvg` |
Unlocks
a VG so that the LVM commands can access or change information
about a particular LVM device.
If the message 0516-366
lsvg: Volume group rootvg is locked
is
ever seen, the above command will unlock the VG in question. |
top
of page
Determines
which PVs belong to the specified VG and re-enters this information
into the ODM. This command is typically used to fix inconsistencies
in the ODM database by reading a copy of the VGDA and recreating
the ODM entries as needed.
| Examples |
What
it does |
| redefinevg
-d hdisk0 rootvg |
Updates
the ODM for a specific VG with the information stored in the
VGDA |
top
of page
Removes one
or more PVs from a VG
| Examples |
What
it does |
| reducevg
rootvg hdisk1 |
Removes
the PV hdisk1 from the VG rootvg. |
| reducevg
-df rootvg hdisk2 |
Removes
hdisk2 from the VG rootvg and all LVs on that PV that weren't
previously removed. |
top
of page
Reads the
base customized information from the boot image and restores it
in the ODM
top
of page
Removes a
logical volume from a volume group
| Examples |
What
it does |
| rmlv
lv00 |
Removes
the LV lv00 from a VG and restores that space back to the
free DASD list. The amount of free disk space returned can
be verified by executing the lsvg
rootvg command before the rmlv command
is executed and after it.
- If
there is a file system associated with the LV to be deleted,
it first must be unmounted.
- Further,
the references to that file system will not be removed
from the /etc/filesystems. The rule when removing a file
system is to first umount the file system and then use
the 'rmfs' command to remove all references of this file
system and it's associated LV.
|
top
of page
Removes logical
partition (mirrored) copies. If no PV named is included with this
command, the last copy created will be removed first.
| Examples |
What
it does |
| rmlvcopy
lv00 2 |
Removes both copies of the LV lv00 |
| rmlvcopy
lv00 1 hdisk2 |
Only
the copy (LV:lv00) that exists on PV hdisk2 is removed. |
top
of page
Reads the
base customized information from the ODM and restores it to the
boot device (hd5).
top
of page
A memory load
algorithm that detects when the system is thrashing and suspends
active processes and delays the initiation of new processes for
a period of time. Since the suspended processes are not scheduled,
their pages in RAM are not being referenced, and are freed for
other processes to use.
When thrashing
stops, the suspended processes are gradually activated again.
The result is that the performance is much more predictable and
constant when RAM is in demand. Schedtune is part of the lpp named
'bosadt.lib.obj' or PTF U412059. AIX does't allocate a page until
you actually attempt to use it.
| Examples |
What
it does |
| schedtune
-h 0 |
Disables
memory load control. Memory load control is ENABLED by default. |
| schedtune |
Determine
current settings for load control. |
| schedtune
-D |
Resets
memory load control to its default characteristics |
top
of page
Synchronizes
stale partitions within VG. syncvg is automatically run when the
VG is varied on ('varyonvg' command).
| Examples |
What
it does |
| syncvg
-v rootvg |
Synchronizes
stale partitions on any PV that belongs to VG rootvg. |
| syncvg
-l lv00 |
| | 
Business Info 