| 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 |
|
|
|
Definitions
| 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
Steps required to re-import VG's after a system re-install
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
Steps required to replace a failing PV from a non-root VG
- 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
How to perform mirroring
- mklv
- mklvcopy
- synvg -l <LV>
top of page
How to move a PV to another SCSI controller
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
How to mirror a boot logical volume
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
bootinfo
| 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
chlv
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
cplv
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
chpv
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
chvg
| 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
exportvg
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
extendvg
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
getlvodm
| 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
importvg
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
ipl_varyon
| Examples |
What it does |
| ipl_varyon -i |
Indicates which PV is your BOOT drive |
top of page
lqueryvg
| 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
lslv
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
lsps
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
lspv
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
lsvg
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
migratepv
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
mklv
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
mklvcopy
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
putlvodm
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
redefinevg
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
reducevg
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
restbase
Reads the base customized information from the boot image and restores it in the ODM
top of page
rmlv
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
rmlvcopy
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
savebase
Reads the base customized information from the ODM and restores it to the boot device (hd5).
top of page
schedtune
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
syncvg
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 |
Synchronizes the LV lv00 so that all copies are identical |
top of page
synclvodm
Will read the VGDA from the PV specified and update the ODM database. 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 |
| synclvodm rootvg hd1 |
Rebuilds the ODM database for a LV hd1, by reading the VGDA. |
top of page
sysdumpdev
Operations performed on the system dump device
| Examples |
What it does |
| sysdumpdev -p sysdumpnull |
Turns off the dump device |
| sysdumpdev -p hd7 |
Reactives the dump device |
| updatevg rootvg |
Resynchronizes the VG information in the ODM |
top of page
varyoffvg
Takes off-line a VG and all associated file systems and LV's.
If a file system or LV is still mounted or open when this command
is executed, the command will fail. A VG that has an active paging LV cannot be varied off or exported.
Use the chps -an <PAGE_LV> to disable the paging LV followed by rebooting the system.
Must umount all file systems on each PV that belongs to a VG before it can be varyed-off
| Examples |
What it does |
1) umount /oracle
2) varyoffvg oracle |
Varys-off ALL PVs associated with the VG named oracle. Essentially makes that VG inaccessible |
top of page
varyonvg
Activates a VG. Takes the information stored in the ODM database and updates the kernel.
| Examples |
What it does |
| varyonvg oracle |
Activates the VG named oracle and makes accessible any LV and/or file system that belongs in that VG |
| varyonvg -m1 oracle |
Will insure the ODM database matches the attributes stored in the VGDA (syncs VGDA to ODM) and reports the status of all PVs. |
| varyonvg -f oracle |
Used if the VG attempting to be varied on was not properly
exported from another system, due to a system crash or some
similiar instance. This force option is only needed when there is a problem with the VGDA on the
imported VG |
top of page |
