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.
