Bug 165366 - Questions about how LVM2 metadata is stored: tools need to display pe_start field
Summary: Questions about how LVM2 metadata is stored: tools need to display pe_start f...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2   
(Show other bugs)
Version: 4.0
Hardware: ia64 Linux
Target Milestone: ---
: ---
Assignee: Alasdair Kergon
QA Contact:
URL: None
Keywords: FutureFeature
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
Reported: 2005-08-08 16:07 UTC by Narasimha Krishnakumar
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: RHBA-2006-0137
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 21:35:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0137 qe-ready SHIPPED_LIVE lvm2 bug fix and enhancement update 2006-03-06 05:00:00 UTC

Description Narasimha Krishnakumar 2005-08-08 16:07:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp

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:

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:

Comment 1 Alasdair Kergon 2005-08-08 16:12:14 UTC
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.

Comment 2 Narasimha Krishnakumar 2005-08-08 16:21:57 UTC
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.

Comment 3 Alasdair Kergon 2005-08-08 17:15:53 UTC
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.

Comment 4 Narasimha Krishnakumar 2005-08-08 17:41:52 UTC
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?


Comment 5 Narasimha Krishnakumar 2005-08-09 19:07:49 UTC

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.

Comment 6 Alasdair Kergon 2005-08-09 19:14:34 UTC
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.

Comment 7 Alasdair Kergon 2005-08-09 19:18:17 UTC
For example, we might need to add fields like 'pe_start' to the 'pvs' output.

Comment 8 Alasdair Kergon 2005-08-09 19:25:02 UTC
Look at a backup file under /etc/lvm/ to see what the new metadata looks like.

Comment 9 Narasimha Krishnakumar 2005-08-09 19:39:56 UTC
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?

Comment 10 Alasdair Kergon 2005-08-09 19:44:26 UTC
"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.

Comment 11 Narasimha Krishnakumar 2005-08-09 19:52:35 UTC
so pe_size is the actual on disk physical extent size as well?

Comment 12 Alasdair Kergon 2005-08-09 20:08:05 UTC
yes - but it only exists while a PV is a member of a VG

Comment 15 Alasdair Kergon 2005-10-20 22:23:13 UTC
pvs -o+pe_start

Comment 19 Red Hat Bugzilla 2006-03-07 21:35:01 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.