AIX

Hi, I have the next doubt about of lost of characteristic of LV

in my original configuration

# lsvg -l ifxvg
ifxvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
aw64m_01 jfs 1 1 1 open/syncd N/A
aw64m_02 jfs 1 1 1 open/syncd N/A
aw64m_03 jfs 1 1 1 open/syncd N/A

However, after of varyoff, vgexport ang vgimport of the ifxvg I have the next output

# lsvg -l ifxvg
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
aw64m_01 1 1 1 open/syncd N/A
aw64m_02 1 1 1 open/syncd N/A
aw64m_03 1 1 1 open/syncd N/A

The Volumes are raw devices of informix DB, the database run succesfully, however my doubt is for that reason the "type" disappear after of vgexport.

IMHO an LV Type of "jfs" is misleading if one wants to create raw devices and should be avoided therefore. Preferably one uses another name for Type, e.g. "raw", so that it is easily visible in the LV's properties what this LV is.

What probably happened is: sbdy created that LV and either assigned the Type or left the Type field empty in which case the default type (i.e. jfs) was chosen. The Informix DB did something to the LV (perhaps the DB did not use a leading offset but wrote over the LV's first 512 byte destroying the Logical Volume Control Block LVCB that way). When exporting the VG you deleted every information of that VG from the server's ODM. As there was nothing to read from the LV during import the Type field now is empty.

That LV handling might have caused a drawback. If you just lost the information about that type you may be lucky. Older versions of AIX had problems when importing/changing LVs who's LVCB was destroyed. I don't know if/how that changed with AIX 5L onwards but you might not be able to import/change the LV's correctly. So check thoroughly that your DB can use the raw devices as it should.