Troubleshooting Starts With Understanding Your Physical Disks’ Attributes -

Any disk—or for that matter physical volume (PV) or hdisk—you might have most likely has some form of data on it. Reviewing disk attributes can reveal much, and not just in terms of managed storage, such as the logical volume manager (LVM) and management of volume groups (VG). Rather, it encompasses the characteristics of the disk itself.

Get to Know These Commands

While the lspv command is well and good, when used on a PV that belongs to a VG, it cannot be used on a PV where the VG has been exported In this instance, to examine the disk(s), even if the VG is “varied off,” you’ll need other commands to examine your disks. .These commands allow you to do this:

readvgda queries the attributes of the disk’s volume group descriptor area (VGDA)
lqueryvg queries the attributes of a VG
lquerypv queries the attributes of a disk when a VG is varied on

These three commands provide virtually everything you’d want to know about a PV and its underlying data so long as it belongs to a VG. Each disk will have a VGDA, which contains information such as the VG it belongs to, the maximum and minimum LVs and PVs, a list of a LV’s details and permissions, stale partitions, and mirrors, if any. The list of information goes on, so I recommend checking it out on your own disks. For example, to learn when a journaled file system (JFS) log was created on a disk, use readvgda and parse the disk in question:

# readvgda hdisk3|grep -p jfslog
------ LV 5 ------
lvname:         loglv01
...
type:           jfslog
created_time:   Mon Dec 24 08:35:56 2012
modified_time:  Mon Dec 24 08:41:29 2012

To find out the VG identifier the disk belongs to:

# readvgda hdisk3|grep vgid
vgid:           00c23bed00004c000000013b61972658

Next, use the lsvg command on your VGs to see what identifier matches. You’ll then have your VG name.

When dealing with VG disk factoring issues, knowing the VG’s current factor size is useful. Before attempting to alter the factor size, the following produces the VG type and the current factor size:

# readvgda hdisk3|grep type
.....    readvgda_type: smallvg
vgtype:         0
# readvgda hdisk3|grep factor
factor:         8

The physical partition size, the number of disks in a VG and all the LV names, can be obtained with a simple one-liner:

# readvgda hdisk3|egrep "pp_size|numpvs|lvname"

The information returned helps create a picture of the LVM layout on a disk, when facing possible issues.

If the VDGA gets fully (not partially) corrupted on a disk, it will no longer know what VG it belongs, and the data on it is lost. The only practical option is to recover the data back to the disk, using a previous copy (printed or text file) of your VG layouts as a guide. This isn’t the only way to recover from a corrupted VDGA, but based on experience, it’s by far the quickest and simplest method.

The following will produce the VG identifier that a disk belongs to. In addition, we parse the disk concerned as its parameter, specifying the “-v” option:

# lqueryvg -p hdisk3 -v  
00c23bed00004c000000013b61972658

Looking at the current VG identifier files in /etc/vg, the directory contains all of the VG identifiers (as empty files) currently on the system. Typically these files are used as an aid by the LVM when locking a VG:

# ls /etc/vg*
vg00C23BED00004C000000013B5FF2084B  vg00C23BED00004C000000013B61972658

A useful option for investigating which LVs reside on a disk is the lqueryvg command, but here the '-l' option is specified. A partial output is shown:

# lqueryvg -p hdisk3 -L
00c23bed00004c000000013b61972658.1   loglv00 1  
00c23bed00004c000000013b61972658.2   fslv00 1  
00c23bed00004c000000013b61972658.3   fslv01 1  
00c23bed00004c000000013b61972658.4   fslv02 1  
00c23bed00004c000000013b61972658.6   lv00 1

This output produces the LVs with the corresponding VG identifier. When you have issues with your VDGA, this command can put you on the right path to determine which LVs need to be recovered. Of course, you need to know the spread of the LVs as well to learn the amount of data to recover. In the output, I would disregard any LV logs. They can easily be taken care of when re-creating the file systems. As an example, look at the spread of fslv01:

# lslv -m fslv01
fslv01:/maps
LP    PP1  PV1               PP2  PV2               PP3  PV3
0001  0269 hdisk3            0055 hdisk2            
0002  0270 hdisk3            0056 hdisk2

Here, fslv01 has another copy on hdisk2, so it might be recoverable without even restoring data. The same information can also be produced using:

readvgda -l hdisk3

To find out which disks belong to a VG, you can use lspv or lsvg -p but it can sometimes be troublesome depending on the severity of the situation and if the disk is corrupted. The following command comes in handy. It produces the pvids of all disks that belong to the same VG by parsing the disk in question. The following shows that two disks belong to the same VG, simply parse the disk in question with the “-P” option:

 # lqueryvg -p hdisk3 -P
00c23bed32883598                2   0  
00525c6a888e32cd                1   0

To return the disks in the VG, use:

# readvgda -o hdisk3|grep pv_id

Of course, you could get the disks and the VG identifier by using the “vPt” option, like so:

# lqueryvg -p hdisk3 -vPt
Physical:       00c23bed32883598                2   0  
                00525c6a888e32cd                1   0  
VGid:           00c23bed00004c000000013b61972658

Assuming you could view all of the disks, the above can be confirmed with:

# lspv |grep appsvg hdisk2          00525c6a888e32cd                    appsvg          active              
hdisk3          00c23bed32883598                    appsvg          active

For an overview of your disks without an overly long output, try:

# lqueryvg -Atp

The most interesting attributes produced will be: maximum LVs, PP size, free PPs, maximum PVPs; the number and names of LVs; total number of disks that belong to the VG; and pvids. The readvgda command, however, will also provide this information.

To see how many used PPs are on a disk, following command is particularly useful, especially when dealing with data migration and you have your own ad hoc scripts doing the work. It requires the VG identifier and disk pvid as its parameters. The following output indicates 684 used PPs on disk3:

# lquerypv -g 00c23bed00004c000000013b61972658 -p 00c23bed32883598 -n
684

Clearer Picture

When experiencing issues with disks, these commands can help to identify where to center your attention in attacking the problem. Using readvgda offers a detailed picture of the characteristics of a disk.

source: http://ibmsystemsmag.com/aix/tipstechniques/systemsmanagement/commands_disk/