1.703: Chlv warning. Is the first 4k of a LV safe?

The first 4k of a raw LV are used to store control block.
Applications that write to the raw disk can overwrite this section
(common applications that do this are Oracle and Sybase).  Commands
that call getlvcb will generate a warning but succeed (since the
control block exists in ODM.  Don't run synclvodm unless you really
want to erase the first 4k and replace it with the info from the ODM.

shieh@austin.ibm.com (Johnny Shieh) has kindly provided the following
explanation:

The logical volume control block (lvcb) is the first 512
bytes of a logical volume.  This area holds important
information such as the creation date of the logical volume,
information about mirrored copies, and possible mount points
in a journaled filesystem.  Certain LVM commands are required
to update the lvcb, as part of completeness algorithms in
LVM.  The old lvcb area is first read and analyzed to see if
it is a valid lvcb.  If the information is verified as valid
lvcb information, then the lvcb is updated.  If the
information is not valid, then the lvcb update is not
performed and the user is given the warning message:

	Warning, cannot write lv control block data

Most of the time, this is a result of database programs
accessing the raw logical volumes (and thus bypassing the
journaled filesystem) as storage media.  When this occurs, the
information for the database is literally written over the lvcb.
Although this may seem fatal, it is not the case.  Once the
lvcb has been overwritten, the user can still:

	1) Extend a logical volume
	2) Create mirrored copies of a logical volume
	3) Remove the logical volume
	4) Create a journaled filesystem with which to mount
		the logical volume (note that this will destroy any
		data sitting in the lvcb area)

However, there is a limitation caused by this deletion of the
lvcb.  The logical volumes with deleted lvcb's face possible,
incomplete importation into other AIX systems.  During an
"importvg", the LVM command will scan the lvcb's of all defined
logical volumes in a volume group for information concerning the
logical volumes.  Surprisingly, if the lvcb is deleted, the
imported volume group will still define the logical volume to
the new AIX system which is accessing this volume group, and
the user can still access the raw logical volume.  However, any
journaled filesystem information is lost and the logical volume
and its associated mount point won't be imported into the new AIX
system.  The user must create new mount points and the availability
of previous data stored in the filesystem is NOT assured.  Also, during
this import of a logical volume with an erased LVCB, some non-jfs
information concerning the logical volume, which is displayed with
the "lslv" command, cannot be found.  When this occurs, the system uses
default logical volume information to populate the logical volume's
ODM information.  Thus, some output from the "lslv" will be inconsistent
with the real logical volume.  If logical volume copies still exist on
the original disks, this information will not be correctly reflected in
the ODM database.  The user should use "rmlvcopy" and "mklvcopy" to
rebuild any logical volume copies and synchronize the ODM.  Finally,
with an erased lvcb, the output from the "lslv" command might be
misleading or unreliable.