vgscan errors

linux-lvm Kelly Corbin 8 participants 20 messages Mar 4, 2002 – Mar 9, 2002

Share & tools

Kelly Corbin

author

2002-03-04 11:22 UTC #0 lore raw

I'm getting the following errors when running vgscan from my custom rescue CD:

vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found inactive volume group "first_vg"
vgscan -- ERROR 2 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c (line 270) vgscan -- ERROR: unable to do a backup of volume group "first_vg"

Unfortunately, I can't figure out why it couldn't write the backup file.
The directory is successfully created, but apparently it can't write
the files there for some reason.

If I do a -v I get a little more info:

vgscan -- storing volume group data of "first_vg" in "/etc/lvmtab.d/first_vg.tmp" vgscan -- storing physical volume data of "first_vg" in "/etc/lvmtab.d/first_vg.tmp" vgscan -- storing logical volume data

of "first_vg" in "/etc/lvmtab.d/first_vg.tmp"

vgscan -- ERROR 2 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c (line 270) vgscan -- ERROR: unable to do a backup of volume group "first_vg"

This is a new machine and all I have done is create the volume group, mount it and copy data down to it. I then rebooted and tried to run vgscan again to confirm the consistency of what I had done and got the above errors. I've done this exact procedure several times before with no problems. I'm using LVM 1.0.1 with kernel 2.4.16 patched for XFS.

Is there anything else I can try? Ideas?

Thanks!

Kelly

Signature · 13 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------

Heinz J . Mauelshagen

2002-03-04 17:26 UTC #1 lore raw

Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.

Regards,
Heinz -- The LVM Guy --

Quoted 33 lines · Kelly Corbin

I'm getting the following errors when running vgscan from my custom rescue CD:
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found inactive volume group "first_vg"
vgscan -- ERROR 2 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c (line 270) vgscan -- ERROR: unable to do a backup of volume group "first_vg"
Unfortunately, I can't figure out why it couldn't write the backup file.
The directory is successfully created, but apparently it can't write
the files there for some reason.
If I do a -v I get a little more info:
vgscan -- storing volume group data of "first_vg" in "/etc/lvmtab.d/first_vg.tmp"
vgscan -- storing physical volume data of "first_vg" in "/etc/lvmtab.d/first_vg.tmp"
vgscan -- storing logical volume data
of "first_vg" in "/etc/lvmtab.d/first_vg.tmp"
vgscan -- ERROR 2 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c (line 270) vgscan -- ERROR: unable to do a backup of volume group "first_vg"
This is a new machine and all I have done is create the volume group, mount it and copy data down to it. I then rebooted and tried to run vgscan again to confirm the consistency of what I had done and got the above errors. I've done this exact procedure several times before with no problems. I'm using LVM 1.0.1 with kernel 2.4.16 patched for XFS.

Quoted 27 lines

Is there anything else I can try? Ideas?

Thanks!

Kelly

Signature · 20 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------


_______________________________________________
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

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Kelly Corbin

author

2002-03-05 14:20 UTC #2 lore raw

Well, after rooting around, it looks like my partition table was screwed up. However, when try to create the vg and lv again (after re-fdisking the disk) it fails at the lv creation. Vgcreate works with no problem; I can reboot and re-activate the vg I just created. When I run lvcreate, I get the following error:

#lvcreate -l23722 -nfirst_lv first_vg
lvcreate -- ERROR 0 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c [line 268] lvcreate -- WARNING: you don't have an automatic backup of "first_vg"
lvcreate -- logical volume "/dev/first_vg/first_lv successfully created.

vgdisplay then shows the correct number of free/used extents (1 free, the rest used), but a vgscan now will fail miserably (before or after reboot) with the same error (ERROR 2)

This is a new disk that I'm trying to setup for the first time.

Ideas?

Thanks.

Quoted 6 lines · Heinz J . Mauelshagen

Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.
Regards,
Heinz -- The LVM Guy --

Signature · 13 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------

Heinz J . Mauelshagen

2002-03-05 15:34 UTC #3 lore raw

Quoted 12 lines · Kelly Corbin

Well, after rooting around, it looks like my partition table was screwed up. However, when try to create the vg and lv again (after re-fdisking the disk) it fails at the lv creation. Vgcreate works with no problem; I can reboot and re-activate the vg I just created. When I run lvcreate, I get the following error:
#lvcreate -l23722 -nfirst_lv first_vg
lvcreate -- ERROR 0 writing volume group backup file /etc/lvmtab.d/first_vg.tmp in vg_cfgbackup.c [line 268] lvcreate -- WARNING: you don't have an automatic backup of "first_vg" lvcreate -- logical volume "/dev/first_vg/first_lv successfully created.

Quoted 7 lines

vgdisplay then shows the correct number of free/used extents (1 free, the rest used), but a vgscan now will fail miserably (before or after reboot) with the same error (ERROR 2)
This is a new disk that I'm trying to setup for the first time.
Ideas?

It is probably too little free space in the root fs.
Because you've got somany extents the size of the metadata backup is bigger as well.

Check your root fs free space, please.

Quoted 36 lines

Thanks.

Quoted 6 lines · Heinz J . Mauelshagen

Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.
Regards,
Heinz -- The LVM Guy --

Signature · 20 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------


_______________________________________________
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

Signature · 15 lines

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Kelly Corbin

author

2002-03-05 16:49 UTC #4 lore raw

Doh! I didn't get what you were saying in your first reply. I'm sure that's it. It's running in an init. ramdisk image and there's very little actual space. Generally speaking, how big do those backups get?

Thanks for your help.

Quoted 20 lines · Heinz J . Mauelshagen

On Tue, Mar 05, 2002 at 02:20:44PM -0600, Kelly Corbin wrote:
It is probably too little free space in the root fs.
Because you've got somany extents the size of the metadata backup is bigger as well.
Check your root fs free space, please.
Quoted 11 lines
Thanks.
Quoted 5 lines · Heinz J . Mauelshagen
Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.
Regards,
Heinz -- The LVM Guy --

Signature · 13 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------

Denie Andriessen

2002-03-05 18:00 UTC #5 lore raw

[linux-lvm] PV-Move fails, now at 127 Pe's...

Hi,

So, I've updated my lvm tools from 0.9.1-beta2 to 1.0.3., and now I seem to have ran into quite some problems..

Ran all test of the move again, and after a few faultless flows I started off again..
We have a volume with 4 * 60, 2 * 80 disk, and another volume (new one, new disk) with 120Gb.

I'd like to move one 60Gb disk to the volume with the 120 Gb disk.

E2fsran nicely, then I started with a PV move, to get /dev/hdc1 out (after failing the first time I tries also to move /dev/hdb1 out) both failing at the same point, that is with 127 PE's moved...

Any takers ?

Regards,
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents

[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups

[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

Heinz J . Mauelshagen

2002-03-06 03:56 UTC #6 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.

Sorry for the inconvenience!

Here's the patch again.

Regards,
Heinz -- The LVM Guy --

tools/lib/liblvm.h 20 Feb 2002 10:49:14 -0000 1.44 renamed from tools/lib/liblvm.h 18 Feb 2002 16:37:18 -0000 1.43 +3 -3

diff -u -B -r1.43 -r1.44
@@ -93,10 +93,10 @@
 #include <time.h>
 #include <limits.h>
 #ifdef _G_LSEEK64
-int lseek64 ( unsigned int, unsigned long long, unsigned int);
+loff_t lseek64 ( int, loff_t, int);
 #define llseek lseek64
 #else
-int llseek ( unsigned int, unsigned long long, unsigned int);
+loff_t llseek ( int, loff_t, int);
 #endif
 
 #include <sys/ioctl.h>

@@ -130,7 +130,7 @@
 #define        LVMTAB                  "/etc/lvmtab"   /* LVM table of VGs */
 #define        LVMTAB_DIR              "/etc/lvmtab.d" /* storage dir VG data */
 #define        LVMTAB_MINSIZE   ( sizeof ( vg_t) + sizeof ( lv_t) + sizeof ( pv_t))
-#define        LVM_DEV                 "/dev/lvm"
+#define        LVM_DEV                 LVM_DIR_PREFIX "lvm"
 #define        VG_BACKUP_DIR           "/etc/lvmconf"
 #define        DISK_NAME_LEN           8
 #define        LV_MIN_NAME_LEN         5

Quoted 64 lines · Denie Andriessen

Hi,
So, I've updated my lvm tools from 0.9.1-beta2 to 1.0.3., and now I seem to have ran into quite some problems..
Ran all test of the move again, and after a few faultless flows I started off again..
We have a volume with 4 * 60, 2 * 80 disk, and another volume (new one, new disk) with 120Gb.
I'd like to move one 60Gb disk to the volume with the 120 Gb disk.
E2fsran nicely, then I started with a PV move, to get /dev/hdc1 out (after failing the first time I tries also to move /dev/hdb1 out) both failing at the same point, that is with 127 PE's moved...
Any takers ?
Regards,
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

Quoted 5 lines

_______________________________________________
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

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Denie Andriessen

2002-03-06 05:02 UTC #7 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

Hi,

So now the volume is inactive, I can't change it, although it notices there is an inactive volume on the disks...

hdb1 and hdc1 both have 127 blocks on there now, and hdg1 has 2*127 block removed. I can't access the data anymore now... Any suggestions on how to get the volume back online, so the data can be accessed ???

-------------
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
-------------

Denie

Quoted 101 lines · Heinz J . Mauelshagen

Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.
Sorry for the inconvenience!
Here's the patch again.
Regards,
Heinz -- The LVM Guy --
Quoted 64 lines · Denie Andriessen
Hi,
So, I've updated my lvm tools from 0.9.1-beta2 to 1.0.3., and now I seem to have ran into quite some problems..
Ran all test of the move again, and after a few faultless flows I started off again..
We have a volume with 4 * 60, 2 * 80 disk, and another volume (new one, new disk) with 120Gb.
I'd like to move one 60Gb disk to the volume with the 120 Gb disk.
E2fsran nicely, then I started with a PV move, to get /dev/hdc1 out (after failing the first time I tries also to move /dev/hdb1 out) both failing at the same point, that is with 127 PE's moved...
Any takers ?
Regards,
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
Quoted 5 lines
_______________________________________________
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
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
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

Signature · 4 lines

----- geekcode sig file -----
GCM/GCS/GS d- s: a C++$ U+++$ P+++$ L++$ E- W+++$ N++ u K w++ O M
V PS PE++ Y+ PGP t+ 5 X++ R tv- b++ DI++ D+ G e+++ h-- r+>++ y++
-----------------------------

Heinz J . Mauelshagen

2002-03-06 05:13 UTC #8 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

Please see my email with explanation I send to yu directly.

Regards,
Heinz -- The LVM Guy --

Quoted 115 lines · Denie Andriessen

Hi,
So now the volume is inactive, I can't change it, although it notices there is an inactive volume on the disks...
hdb1 and hdc1 both have 127 blocks on there now, and hdg1 has 2*127 block removed. I can't access the data anymore now... Any suggestions on how to get the volume back online, so the data can be accessed ???
-------------
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
-------------
Denie
Quoted 95 lines · Heinz J . Mauelshagen
Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.
Sorry for the inconvenience!
Here's the patch again.
Regards,
Heinz -- The LVM Guy --
Quoted 64 lines · Denie Andriessen
Hi,
So, I've updated my lvm tools from 0.9.1-beta2 to 1.0.3., and now I seem to have ran into quite some problems..
Ran all test of the move again, and after a few faultless flows I started off again..
We have a volume with 4 * 60, 2 * 80 disk, and another volume (new one, new disk) with 120Gb.
I'd like to move one 60Gb disk to the volume with the 120 Gb disk.
E2fsran nicely, then I started with a PV move, to get /dev/hdc1 out (after failing the first time I tries also to move /dev/hdb1 out) both failing at the same point, that is with 127 PE's moved...
Any takers ?
Regards,
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
Quoted 5 lines
_______________________________________________
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
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Quoted 25 lines

Quoted 6 lines
_______________________________________________
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
Signature · 13 lines
----- geekcode sig file -----
GCM/GCS/GS d- s: a C++$ U+++$ P+++$ L++$ E- W+++$ N++ u K w++ O M
V PS PE++ Y+ PGP t+ 5 X++ R tv- b++ DI++ D+ G e+++ h-- r+>++ y++
-----------------------------




_______________________________________________
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

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz J . Mauelshagen

2002-03-06 05:37 UTC #9 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

In reply to Denie Andriessen

Denie,

got service unavailable for [email protected] :-(

Regards,
Heinz -- The LVM Guy --

Quoted 115 lines · Denie Andriessen

Hi,
So now the volume is inactive, I can't change it, although it notices there is an inactive volume on the disks...
hdb1 and hdc1 both have 127 blocks on there now, and hdg1 has 2*127 block removed. I can't access the data anymore now... Any suggestions on how to get the volume back online, so the data can be accessed ???
-------------
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
-------------
Denie
Quoted 95 lines · Heinz J . Mauelshagen
Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.
Sorry for the inconvenience!
Here's the patch again.
Regards,
Heinz -- The LVM Guy --
Quoted 64 lines · Denie Andriessen
Hi,
So, I've updated my lvm tools from 0.9.1-beta2 to 1.0.3., and now I seem to have ran into quite some problems..
Ran all test of the move again, and after a few faultless flows I started off again..
We have a volume with 4 * 60, 2 * 80 disk, and another volume (new one, new disk) with 120Gb.
I'd like to move one 60Gb disk to the volume with the 120 Gb disk.
E2fsran nicely, then I started with a PV move, to get /dev/hdc1 out (after failing the first time I tries also to move /dev/hdb1 out) both failing at the same point, that is with 127 PE's moved...
Any takers ?
Regards,
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
Quoted 5 lines
_______________________________________________
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
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Quoted 25 lines

Quoted 6 lines
_______________________________________________
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
Signature · 13 lines
----- geekcode sig file -----
GCM/GCS/GS d- s: a C++$ U+++$ P+++$ L++$ E- W+++$ N++ u K w++ O M
V PS PE++ Y+ PGP t+ 5 X++ R tv- b++ DI++ D+ G e+++ h-- r+>++ y++
-----------------------------




_______________________________________________
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

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Denie Andriessen

2002-03-06 19:07 UTC #10 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

In reply to Denie Andriessen

Hi,

Yes, I know, it's late again, but that's just the burden of having a day job..
Stiil I seem to be unable to get the volume back online/accesable still...

The volume still doesn't 'want' (?) to becognised.. PVscan sees it, vgck does not agree to it, vgscan neither..

Short:
After the upgrade to LVM1.0.3. and before aplying the 'sig problem' patch.. we tried to do some PV moves, from then onwards it seemed no to get any better.... SInce the reboot the volume was not accesible anymore...

Long, long, very long log on:
http://blok14b.gimmie.tudelft.nl/~denie/LVM/log.txt

Main question is, shoulld I stick to the the about 380Gb of data or reformat and start over new ?
The data is not really 'that' improtant' as it's just what the student's overhere (about 120 of them) can grab together from the net for internal use only in our house only
... But still there were quite a few good things there..

Regards,
Denie Andriessen

Denie Andriessen

2002-03-08 14:19 UTC #11 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

So,

Found the 1.0.4.-pre1.tar.bz2, compiled, installed
(Hey, the fix to the 'cast' problem was already in there, although an old version of the file was also!)
Was: Unable to clear last PE

Quoted 2 lines

Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.

Now:
- it *IS* possible to do the vgscan
- it *IS* possible to turn the volume active again
- it *IS* possible to do PV move again, and it does NOT fail on PE 127 anymore
- ALL data was still there !
- Everything is up and running !
- I am very very very happy !!!

Thanks a LOT, keep up the amazing work !!

Very kind regards,
Denie Andriessen

----- Original Message -----
<LOTS CUT OUT>

Hi,

So now the volume is inactive, I can't change it, although it notices there is an inactive volume on the disks...

Quoted 3 lines · Denie Andriessen

Hi,
Could it be the: "known misalignment issue we had in the 0.9.1 Beta

series"

Quoted 2 lines

(after reading through lots of messages)
https://mail.sistina.com/pipermail/linux-lvm/2002-February/010724.html

Yes, that's my guess.

Quoted 2 lines

Is an upgrade 'dangerous' ? (risk of loosing data)

Well, the way to go is:

- pvmove /dev/hdf2 # move your data back to /dev/hdf1
- vgreduce test12 /dev/hdf2
- update to LVM 1.0.3 (or wait for 1.0.4 which will be released soon)
- pvcreate /dev/hdf2
- vgextend test12 /dev/hdf2
- pvmove /dev/hdf1

Quoted 4 lines

Cheers,
Denie

Denie Andriessen

2002-03-06 05:04 UTC #12 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

In reply to Heinz J . Mauelshagen

Hi,

So now the volume is inactive, I can't change it, although it notices there is an inactive volume on the disks...

Denie

Quoted 20 lines · Heinz J . Mauelshagen

Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.
Sorry for the inconvenience!
Here's the patch again.
Regards,
Heinz -- The LVM Guy --
Quoted 9 lines
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

Denie Andriessen

2002-03-06 09:01 UTC #13 lore raw

Re: [linux-lvm] PV-Move fails, now at 127 Pe's...

In reply to Heinz J . Mauelshagen

Hi,

Applied the patch, but 1 problem still remains..

It claims that the VG "volume" is an unknown volume, and therefor it also does not want to start to do a pvmove... :(

Is all data lost now ?

Denie

Quoted 52 lines · Heinz J . Mauelshagen

Well, you hit the cast problem I reported a fix for on linux-lvm shortly after the LVM 1.0.3 release.
Sorry for the inconvenience!
Here's the patch again.
Regards,
Heinz -- The LVM Guy --
Quoted 42 lines
------- info-----------
pvmove -- writing physical extent part of VGDA on destination "/dev/hdg1"
lv: /dev/volume/data[1] old_dev: 22:01 new_dev: 34:01 old_pe_sector:
4176642 new_pe_sector: 47036865
pvmove -- opening output physical volume "/dev/hdg1"
pvmove -- llseeking input physical volume "/dev/hdc1"
pvmove -- llseeking output physical volume "/dev/hdg1"
pvmove -- /dev/hdc1 [PE 127 [data [LE 7328]] -> /dev/hdg1 [PE 1435] [128/3577]
pvmove -- locking physical extent 127 of "/dev/hdc1" in kernel pvmove -- about to read input physical volume "/dev/hdc1" and to write output physical volume "/dev/hdg1"
pvmove -- ERROR reading input physical volume "/dev/hdc1" (still 7733248 bytes to read)
pvmove -- ERROR "pv_move_pe(): read input PV" moving physical extents
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgscan
vgscan -- reading all physical volumes (this may take a while...) vgscan -- found active volume group "volume"
vgscan -- only found 20391 of 20518 LEs for LV /dev/volume/data (0) vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "volume" from physical volume(s)
vgscan -- found active volume group "mp3volume"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume groups
[root@localhost /]# lvscan
lvscan -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
[root@localhost /]# vgdisplay -v volume
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

Kelly Corbin

author

2002-03-07 11:17 UTC #14 lore raw

In reply to Kelly Corbin

OK, now I have another problem. I got vgscan to run fine now off of my boot CD, but now the system fails the vgscan on boot (/ is an LVM) with an 'ERROR 28 writing volume group backup file /etc/...'

I'm assuming this is because the initrd created by lvmcreate_initrd is not big enough to accomodate the metadata backup. What size is this generally (lvmcreate_initrd says it calculates this automatically) and to what size should I set this manually to get this to work? How much space do I need for the backups during vgscan?

Thanks.

Quoted 29 lines · Kelly Corbin

Doh! I didn't get what you were saying in your first reply. I'm sure that's it. It's running in an init. ramdisk image and there's very little actual space. Generally speaking, how big do those backups get?
Thanks for your help.
Quoted 21 lines · Heinz J . Mauelshagen
On Tue, Mar 05, 2002 at 02:20:44PM -0600, Kelly Corbin wrote:
It is probably too little free space in the root fs.
Because you've got somany extents the size of the metadata backup is bigger as well.
Check your root fs free space, please.
Quoted 12 lines
Thanks.
Quoted 5 lines · Heinz J . Mauelshagen
Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.
Regards,
Heinz -- The LVM Guy --

Signature · 13 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------

Heinz J . Mauelshagen

2002-03-08 02:47 UTC #15 lore raw

Quoted 6 lines · Kelly Corbin

OK, now I have another problem. I got vgscan to run fine now off of my boot CD, but now the system fails the vgscan on boot (/ is an LVM) with an 'ERROR 28 writing volume group backup file /etc/...'
I'm assuming this is because the initrd created by lvmcreate_initrd is not big enough to accomodate the metadata backup.

Exactly.

Quoted 4 lines

What size is this
generally (lvmcreate_initrd says it calculates this automatically) and to what size should I set this manually to get this to work? How much space do I need for the backups during vgscan?

Calculate your given initrd size plus your /etc/lvconf/* backup sizes you need to store in the initrd once vgscan is run
and change the INITRDSIZE to that number in kilobytes + 1MB.

Regards,
Heinz -- The LVM Guy --

Quoted 29 lines

Thanks.
Quoted 24 lines · Kelly Corbin
Doh! I didn't get what you were saying in your first reply. I'm sure that's it. It's running in an init. ramdisk image and there's very little actual space. Generally speaking, how big do those backups get?
Thanks for your help.
Quoted 16 lines · Heinz J . Mauelshagen
On Tue, Mar 05, 2002 at 02:20:44PM -0600, Kelly Corbin wrote:
It is probably too little free space in the root fs. Because you've got somany extents the size of the metadata backup is bigger
as well.
Check your root fs free space, please.
Quoted 6 lines
Thanks.
Heinz J . Mauelshagen wrote:

Quoted 31 lines

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Error 2 is ENOENT (no entry).
Could be a space problem in case / run full.
Regards,
Heinz -- The LVM Guy --

Signature · 20 lines

--------------------------------------------
-- Kelly Corbin
-- Systems Administrator
--
-- http://www.theiqgroup.com
-- The Future of eServices...
--
-- The IQ Group, Inc.
-- 6740 Antioch Suite 110
-- Merriam, KS 66204
-- (913)-722-6700 x105
-- Fax (913)722-7264
--------------------------------------------


_______________________________________________
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

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200

                                                       FAX 924446

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Andreas Dilger

2002-03-08 03:12 UTC #16 lore raw

Quoted 10 lines · Heinz J . Mauelshagen

Quoted 6 lines · Kelly Corbin
OK, now I have another problem. I got vgscan to run fine now off of my boot CD, but now the system fails the vgscan on boot (/ is an LVM) with an 'ERROR 28 writing volume group backup file /etc/...'
I'm assuming this is because the initrd created by lvmcreate_initrd is not big enough to accomodate the metadata backup.
Exactly.

Quoted 8 lines

Quoted 4 lines
What size is this
generally (lvmcreate_initrd says it calculates this automatically) and to what size should I set this manually to get this to work? How much space do I need for the backups during vgscan?
Calculate your given initrd size plus your /etc/lvconf/* backup sizes you need to store in the initrd once vgscan is run
and change the INITRDSIZE to that number in kilobytes + 1MB.

I think a lot of people have this same problem (not enough free space in initrd). Can't we just disable backups somehow? It's the initrd after all, so it's not like the backups are useful. Alternately, it is better to just fix the script to have more leeway in the INITRDSIZE in the first place.

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

Heinz J . Mauelshagen

2002-03-08 06:37 UTC #17 lore raw

Quoted 16 lines · Andreas Dilger

Quoted 15 lines · Heinz J . Mauelshagen
Quoted 6 lines · Kelly Corbin
OK, now I have another problem. I got vgscan to run fine now off of my boot CD, but now the system fails the vgscan on boot (/ is an LVM) with an 'ERROR 28 writing volume group backup file /etc/...'
I'm assuming this is because the initrd created by lvmcreate_initrd is not big enough to accomodate the metadata backup.
Exactly.
Quoted 4 lines
What size is this
generally (lvmcreate_initrd says it calculates this automatically) and to what size should I set this manually to get this to work? How much space do I need for the backups during vgscan?

Quoted 6 lines

Quoted 3 lines
Calculate your given initrd size plus your /etc/lvconf/* backup sizes you need to store in the initrd once vgscan is run
and change the INITRDSIZE to that number in kilobytes + 1MB.
I think a lot of people have this same problem (not enough free space in initrd). Can't we just disable backups somehow?

Andreas,

vgscan creates cache copies of the metadata in /etc/lvmtab.d/.

So if just vgscan and "vgchange -ay" run in the initrd, there's one copy for every VG in /etc/lvmtab.d/ *and*

export LVM_VG_MAX_BACKUPS=no

disables automatic backup creation in /etc/lvmconf/.

vgchange needs little modification to read the data directly from the devices rather than from the cache files.

Should I put that into LVM 1.0.4? ;-)

Quoted 17 lines

It's the initrd after
all, so it's not like the backups are useful. Alternately, it is better to just fix the script to have more leeway in the INITRDSIZE in the first place.
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
_______________________________________________
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

Signature · 15 lines

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Goetz Bock

2002-03-08 16:50 UTC #18 lore raw

Quoted 5 lines · Heinz J . Mauelshagen

vgscan creates cache copies of the metadata in /etc/lvmtab.d/.
So if just vgscan and "vgchange -ay" run in the initrd, there's one copy for every VG in /etc/lvmtab.d/ *and*

Quoted 8 lines

export LVM_VG_MAX_BACKUPS=no
disables automatic backup creation in /etc/lvmconf/.
vgchange needs little modification to read the data directly from the devices rather than from the cache files.
Should I put that into LVM 1.0.4? ;-)

Yes, please do this.

(While I don't need this, my initrd is big enough and moves over to tempfs very soon, but it would so much nicer to just do

vgchange -a y /dev/<root vg>/<root lv>

and save vgscan.
)

Just my 0.02 Euro,
Goetz.

Laurentiu Simion

2002-03-09 11:47 UTC #19 lore raw

[linux-lvm] Mounting Reiserfs errors

I am running LVM with ext3 and recently with Reiserfs on Mandrake 8.1 (kernel 2.4.8-26) I had no problems for quite a time with ext3 but when I have tried to play with Reiserfs I've got into big big trouble.

This is the /proc/lmv/global listing:

------------------------------------------------------------------------
LVM module version LVM 0.9.1_beta7(ish) (20 June 2001)

Total: 2 VGs 3 PVs 5 LVs (4 LVs open 4 times)

Global: 44714 bytes malloced IOP version: 10 0:09:22 active

VG: system [1 PV, 4 LV/4 open] PE Size: 4096 KB
Usage [KB/PE]: 9043968 /2208 total 6963200 /1700 used 2080768 /508
free
PV: [AA] ide/host0/bus0/target0/lun0/part6 9043968 /2208 6963200
/1700 2080768 /508

    LVs: [AWDL  ] 1                           409600 /100      1x open
         [AWDL  ] 2                          5201920 /1270     1x open
         [AWDL  ] 3                           716800 /175      1x open
         [AWDL  ] 4                           634880 /155      1x open

VG: depot [2 PV, 1 LV/0 open] PE Size: 4096 KB
Usage [KB/PE]: 4321280 /1055 total 2097152 /512 used 2224128 /543
free
PVs: [AA] ide/host0/bus0/target0/lun0/part7 2064384 /504 2064384
/504 0 /0

       [AA] ide/host0/bus0/target0/lun0/part8  2256896 /551        32768

/8 2224128 /543
LV: [AWDL ] lvol1 2097152 /512 close
--------------------------------------------------------------------------

The VG with problems is "depot". Is split on 2 disk partitions and has one LV using half of the space.
I was able at the beginning to mount /dev/depot/lvol1 as reiserfs but after a FS resize I've got the following error trying to mount the FS:

# mount -t reiserfs /dev/depot/lvol1 /u0
mount: wrong fs type, bad option, bad superblock on /dev/depot/lvol1,
       or too many mounted file systems

I was running all the possible checks on /dev/depot/lvol1 as per below:

# reiserfsck /dev/depot/lvol1

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.x.1b

Will read-only check consistency of the filesystem on /dev/depot/lvol1 Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes):Y [root@cr227180-a lvm]# reiserfsck /dev/depot/lvol1

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.x.1b

Will read-only check consistency of the filesystem on /dev/depot/lvol1 Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes):Yes
###########
reiserfsck --check started at Sat Mar 9 12:44:21 2002
###########
reiserfs_fetch_ondisk_bitmap: bread failed reading bitmap (491520) Replaying journal..
0 transactions replayed
Checking S+tree..ok
Comparing bitmaps..on-disk bitmap does not match to the correct one. 32767 bits differ
on-disk bitmap does not match to the correct one. Checking Semantic tree...
ok
There were found 1 corruptions which can be fixed with --fix-fixable
###########
reiserfsck finished at Sat Mar 9 12:44:26 2002
###########

I forced a FS repair but it will not repair. It seems there are no major corruptions on the FS, but I cannot mount.

# reiserfsck /dev/depot/lvol1 --fix-fixable

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.x.1b

Will check consistency of the filesystem on /dev/depot/lvol1 Will fix what can be fixed w/o --rebuild-tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes):Yes
###########
reiserfsck --fix-fixable started at Sat Mar 9 12:45:34 2002
###########
reiserfs_fetch_ondisk_bitmap: bread failed reading bitmap (491520) Replaying journal..
0 transactions replayed
Checking S+tree..ok
Comparing bitmaps..on-disk bitmap does not match to the correct one. 32767 bits differ
Trying to fix bitmap ..
bitmaps were not recovered.
You can either run rebuild-tree or live with some leaked space
Checking Semantic tree...
ok
No corruptions found
There are on the filesystem:
Leaves 658
Internal nodes 6
Directories 106
Other files 2335
Data block pointers 133863 (zero of them 0)
Safe links 0
###########
reiserfsck finished at Sat Mar 9 12:45:40 2002
###########

I have upgraded the LVM module to 1.0.1.-rc4 in a 2.4.18 Kernel, but nothing is changed.

Can somebody show me light at the end of the tunnel PLEASE?

Thanks in advance,

Laurentiu