Red Hat Bugzilla – Bug 165366
Questions about how LVM2 metadata is stored: tools need to display pe_start field
Last modified: 2007-11-30 17:07:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp 220.127.116.11)
Description of problem:
The problem is finding the metadata relating to LVM2 on disk. Block 0(zero) of a LVM2 managed disk has data such as ID, and various information regarding the Physical volume (PV). This information should be written to disk starting at offset 0(zero) and it is not being written at this time.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. pvcreate /dev/sdf
2. vgcreate samplevg /dev/sdf
3. Open the device (/dev/sdf) read only (using open system call)
4. read 512 bytes from the beginning of the device.
Actual Results: The actual result is the block read at offset zero is a zeroed block
Expected Results: The expected result is a valid pv_disk structure.
lvm2 supports multiple on-disk formats.
By default a new format is used which does not use the first sector unless you
explicitly ask it to.
If you want to use the old format, like LVM1 did, use -M1 on the command line or
change the default in lvm.conf.
Could you tell me at what offset i can get the new format data at? Also i
looked at the lvm utility and it does look at offset 0. Please clarify.
Correct, it looks at offset 0 - but it looks in other places too!
There are some significant differences in the way the data is stored compared
with lvm1: please use the lvm2 tools to access the metadata. Otherwise you'd
have to exactly replicate the logic lvm2 uses, and what's the point?
What are you trying to do? Have you looked at all the options that 'pvs' gives
you? If there's something missing that you need, I can try to add it.
I am very much interested in the data in the 'pv_disk' structure. The pv_disk
structure contains all the info about the on disk pv address, size, pe on disk
address, size etc. Not all of the information in the pv_disk structure is
available thro the pvs command line. I was looking at the '_read_pvd' routine
in the lvm2 tools and it tries to read the pv_disk structure at offset 0 but
the data is just not at offset 0. Could you let me know how i can get the
I further investigated the metadata problem and found that i need what is
avaliable thro the pvdata command that was supported in the LVM1 version. The
command is unavailable in the LVM2 version. It would be very helpful if you
could add the ondisk fields especially the pe_on_disk_base, pe_on_disk_size,
pv_on_disk_base and pv_on_disk_size to the pvdisplay command or if you could
provide me the location on disk where i can get these values. Thanks in advance
for your response.
Those fields don't exist like that in the new metadata format!
You need to tell us what you're trying to achieve so we can work out an
appropriate way to do this with LVM2.
For example, we might need to add fields like 'pe_start' to the 'pvs' output.
Look at a backup file under /etc/lvm/ to see what the new metadata looks like.
I looked at both backup and archive in /etc/lvm a while back and it just has
the pe_start in (what units?) number of units. Is the pe_start the actual
starting address of the physical extents on disk? I am interested in the offset
on disk at which the actual extent data starts. Then the pe_size that can be
obtained from pvdisplay is another thing that i am interested in. Is the
pe_size displayed thro pvdisplay the actual on disk size that a physical extent
(pe) has? In other words are pe_size and pe_start equivalent to pe_on_disk_size
"I am interested in the offset on disk at which the actual extent data starts."
That's pe_start (in 512-byte sectors). I'll get it added to the display tools.
so pe_size is the actual on disk physical extent size as well?
yes - but it only exists while a PV is a member of a VG
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.