BYTE OFFSET FOR RAW LOGICAL VOLUMES AND RAW DISK
ITEM: RTA000038987
We just installed Informix On-Line on 3.2.4. We have two volume
groups. One volume group contains the operating system, the other
contain user programs and data. On two drives within the users
volume group, I have defined logical volumes for Informix. Informix
is writing to these logical volumes directly, so they do not contain
AIX JFS's. When we installed Informix, we specified an offset of
8KB to avoid writing over any control information. Is this a large
enough offset? We will NOT be using the mirroring function of AIX
on these logical volumes. On another logical volume we did NOT
specify an offset. My concern was that the logical volume control
block would get overwritten because of this. To check this I
issued dd if=/dev/hd20 ibs=1 count=65384 of=/tmp/hd20.out. When I
did an od -a /tmp/hd20.out, I saw what appeared to be valid control
information for the LVM. Is this a valid check? Do I have to issue
getlvcb -AT hd20 to determine if the information is corrupted?
For some other drives in the system, I did NOT add them to any
volume group. These drives are accessed directly by Informix. An
lspv shows them to have valid PVID's. We also used an 8KB offset
for these drives. I am pretty sure that since these drives are not
part of any volume group, an 8K offset is large enough.
Do I need to reconfigure my raw logical volumes in the user volume
group with a larger offset? What offset do I use? The programmers
reference seems to mention that the first 128 sectors
(512 Bytes/sector) should be reserved for the LVM. But I think this
may be overkill since we are not doing mirroring.
---------- ---------- ---------- --------- ---------- ----------
A:
Under the "mklv" command, InfoExplorer documents that the first few
hundred bytes within the logical volume contain the logical volume
control block (LVCB). Logical volume data begins on the second
512-byte block. I tested this and verified that writing after the
512 bytes did not affect the LVCB. Therefore an 8K offset, although
very generous, will not overwrite the LVCB. The dd command and
"getlvcb -AT LVNAME" command will both read the LVCB. With the dd
command however, you will need to be familiar with the unformatted
output. I favor using getlvcb, as its output makes it easier to
notice if LVCB corruption exists.
InfoExplorer states (in the article "Understanding Physical Volumes
and the Logical Volume Device Driver") a physical volume reserves the
first 128 sectors to store various types of DASD configuration and
operation information. The /usr/include/sys/hd_psn.h file describes
the information stored on the reserved sectors. In summary, the
sector layout is:
o The boot record (sector 0) contains information that allows the
ROS to boot the system. It also contains the PVID.
o The MWC record (sector 2 and 3) used by LVM identifies which
logical partitions may be inconsistent if the system is not
shutdown properly.
o The LVM record (sector 7) consists of one sector and contains
information used by the LVM when the physical volume is a member
of the volume group.
o The bad-block directory (sector 8-29) records the blocks on the
physical volume that have been diagnosed as unusable by LVDD (part
of LVM).
o Sectors 64, 70, 71 consist of LVM backup information.
o The area following the first 128 sectors contains the VGDA/VGSA
for the LVM.
o End of the physical volume is reserved as a relocation pool for
bad blocks that are are software-relocated by LVM.
It seems as though everything after sector 0 is related to LVM.
Sector 0 contains the important PVID information that should not be
overwritten. Therefore, the offset can be set to 512-bytes (starting
at sector 1), if LVM is not being used and the disk is being used as
a raw device.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q652960 7QGDZ
Additional search words:
$$A AIX BYTE CUSTORG DASD DISC DISKETTE IRRISC IX JAN94 LOGICAL
OFFSET OZIBM OZNEW RAW RISC VOLUMES 7QGDZ
WWQA: ITEM: RTA000038987 ITEM: RTA000038987
Dated: 11/1996 Category: RISCOHW
This HTML file was generated 99/06/24~12:43:15
Comments or suggestions?
Contact us