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
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.