Skip to contentSkip to conversation

Problem with vgscan "only found 626 of 625 LEs for LV"

linux-lvm Tomas Edwardsson 2 participants 3 messages Sep 11, 2001 – Sep 12, 2001 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

I had already tried the vgcfgrestore, it didn't seem to help but I discovered that the UUID for one of my PVs was missing so I ran the uuid-fixer and now they all have UUIDs again (don't know if that is relevant).

I have run the pvdata on all my PVs although I think the right one is the following file run with pvdata -avP /dev/hdd1:
http://vefur.hp.is/lvm/pvdata-hdd1.txt

I also documented a few more commands:

pvdata -avP /dev/hdb2, http://vefur.hp.is/lvm/pvdata-hdb2.txt
pvdata -avP /dev/hdc2, http://vefur.hp.is/lvm/pvdata-hdc2.txt
pvscan, http://vefur.hp.is/lvm/pvscan.txt
vgscan, http://vefur.hp.is/lvm/vgscan.txt

Quoted 24 lines · Tomas Edwardsson
Quoted 13 lines · Tomas Edwardsson

Hmm, anyone able to help with this? All my data is currently offline and I really need it back so if anyone could help please!

- Tommi

Quoted 7 lines · Tomas Edwardsson

Here is what vgscan shows:

vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found inactive volume group "vg00"
vgscan -- only found 626 of 625 LEs for LV /dev/vg00/lvol1 (0)
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "vg00" from physical volume(s) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating "/etc/lvmtab" and "/etc/lvmtab.d"

It looks like the PE table does not match what is in the LV table for
that LV (i.e. the PE table has 626 PEs that claim to be part of the LV,
but the LV says it has only 625 LEs allocated). Two possibilities: you recently added an LE to the LV and you had a crash (or an LVM bug), or somehow you had an error writing to disk. You can try
restoring a copy of the metadata with vgcfgrestore to see if it helps. Failing that, check pvdata -avP <disk> to see what is wrong. Cheers, Andreas --
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

#2 lore raw
Quoted 7 lines · Tomas Edwardsson

I had already tried the vgcfgrestore, it didn't seem to help but I discovered that the UUID for one of my PVs was missing so I ran the uuid-fixer and now they all have UUIDs again (don't know if that is relevant).

I have run the pvdata on all my PVs although I think the right one is the following file run with pvdata -avP /dev/hdd1:
http://vefur.hp.is/lvm/pvdata-hdd1.txt

Yes, this clearly shows that lvol1 has 625 LEs (in the LV data), but it has PE 0-625 from that PV assigned to it (total of 626 PEs). I don't know which one is correct, nor how it got that way. If you have a filesystem on that LV, you could find out how big the fs is to figure out which value needs fixing. For ext2, you can do:

dumpe2fs -h /dev/vg00/lvol1

and figure out if it is 2500MB (625 LE) or 2504MB (626LE). Then (the fun part) you need to go and edit either the LV table or the PE table to have the right numbers in it. I'm guessing the LV table is wrong (and even if not, it is safer to add the PE to the end than to truncate your filesystem).

dd if=/dev/hdd1 of=/hdd.sav bs=1024 count=188 # backup LVM metadata
dd if=/dev/hdd1 of=/lv1.dat bs=1 skip=43008 count=328 # get lvol1 metadata
od -Ad -tx1 /lv1.dat # show lvol1 metadata

# 625 = 0x271 which you should see at offset 300, 301 of the LV struct # 626 = 0x272 = 0x02 0x72, 0x72 = "r" in ASCII, so we write this into LV
echo "r" | dd of=/lv1.dat count=1 seek=300 # write 0x72 to LE count

od -Ad -tx1 /lv1.dat # show lvol1 metadata

# we should now see 0x72 0x02 0x00 0x00 at offset 300 of the LV metadata

dd if=/lv1.dat of=/dev/hdd1 bs=1 seek=43008 # write LV meta to disk
pvdata -avP /dev/hdd1 # verify all is well
vgscan # should be OK now

Cheers, Andreas

Signature · 3 lines
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
#3 lore raw

Well, problem number 1. vgscan fails and therefore vgchange does also.

]# ll -d /dev/vg00
ls: /dev/vg00: No such file or directory

I ran the rest of the commands just the same since we have a backup. After I did that it seems all LV and LE info has evaporated.

Current pvdata is http://vefur.hp.is/lvm/pvdata-hdd1-new.txt

Thanks, Tommi

Quoted 49 lines · Andreas Dilger
Quoted 7 lines · Tomas Edwardsson

I had already tried the vgcfgrestore, it didn't seem to help but I discovered that the UUID for one of my PVs was missing so I ran the uuid-fixer and now they all have UUIDs again (don't know if that is relevant).

I have run the pvdata on all my PVs although I think the right one is the following file run with pvdata -avP /dev/hdd1:
http://vefur.hp.is/lvm/pvdata-hdd1.txt

Yes, this clearly shows that lvol1 has 625 LEs (in the LV data), but it has PE 0-625 from that PV assigned to it (total of 626 PEs). I don't know which one is correct, nor how it got that way. If you have a filesystem on that LV, you could find out how big the fs is to figure out which value needs fixing. For ext2, you can do:

dumpe2fs -h /dev/vg00/lvol1

and figure out if it is 2500MB (625 LE) or 2504MB (626LE). Then (the fun part) you need to go and edit either the LV table or the PE table to have the right numbers in it. I'm guessing the LV table is wrong (and even if not, it is safer to add the PE to the end than to truncate your filesystem).

dd if=/dev/hdd1 of=/hdd.sav bs=1024 count=188 # backup LVM metadata
dd if=/dev/hdd1 of=/lv1.dat bs=1 skip=43008 count=328 # get lvol1 metadata
od -Ad -tx1 /lv1.dat # show lvol1 metadata

# 625 = 0x271 which you should see at offset 300, 301 of the LV struct # 626 = 0x272 = 0x02 0x72, 0x72 = "r" in ASCII, so we write this into LV
echo "r" | dd of=/lv1.dat count=1 seek=300 # write 0x72 to LE count

od -Ad -tx1 /lv1.dat # show lvol1 metadata

# we should now see 0x72 0x02 0x00 0x00 at offset 300 of the LV metadata

dd if=/lv1.dat of=/dev/hdd1 bs=1 seek=43008 # write LV meta to disk
pvdata -avP /dev/hdd1 # verify all is well
vgscan # should be OK now

Cheers, Andreas

Signature · 10 lines
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert


_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html