From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp 5.0.2.4) 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): LVM 2.01.14 How reproducible: Always 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. Additional info:
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 pv_disk data? Thanks.
Hi, 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 and pe_on_disk_base?
"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
pvs -o+pe_start
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. http://rhn.redhat.com/errata/RHBA-2006-0137.html