lvm 0.8 to 0.9 conversion?
Subsystems (2)
Andre,
One of my two volume groups, unfortunately the one with
/usr, /var, /opt, and /home, isn't recognized by 0.9's vgscan when
I reboot under 2.4.0-test13-pre4. But since the second volume
group is visible, and you just told meit should be, then I can just copy volumes over under test13-pre3 and destroy and recreate the first volume group.
Thanks,
-- todd --
Quoted 2 lines · Todd M. Roy
Quoted 2 lines
Now that in 2.4.0-test12-pre4, lvm 0.9 has replaced 0.8, is it
possible
Quoted 4 lines
Quoted 2 lines
to do a conversion of lvm created physical volumes, volume groups and logical volumes from 0.8 to 0.9?
on-disk format isn't changed so no conversion is needed. You only need to upgrade the lvm tools to use the new kernel driver, grab the
tools from
www.sistina.com.
Andre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Todd M. Roy
group is visible, and you just told meit should be, then I can just copy volumes over under test13-pre3 and destroy and recreate the first volume group.
Is it possible you had a snapshot in the volume group when you started lvm 0.9 the first time? snapshots are not persistent on pre3 so it doesn't make sense to left them before rebooting the kernel, and maybe lvmtools 0.9 doesn't cope correctly with non persistent snapshot created by 0.8 driver (trivial to temporarly workaround, just delete any snapshot volume before using 0.9 lvm :).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
I've been on vacation....
Nope, no snapshots.
Well, I couldn't get my orginal volume group visible under both lvm 0.8 and 0.9. I don't know why. So I grabbed a big empty hard disk, created a new volume group that was visible under both, dded all the logical volumes over to it, updated fstab and removed the offending vg. I've yet to recreate the original vg, copy stuff back and remove the new drive. I should point out that the offending vg was relatively ancient, I think I created it when 0.7 was king under some something like 2.2.14. Now I'm running 2.4.0-ac4 and all works well.
Quoted 13 lines
Date: Wed, 27 Dec 2000 20:53:36 +0100
From: Andrea Arcangeli <[email protected]>
Cc: [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.ascQuoted 3 lines · Todd M. Roy
group is visible, and you just told meit should be, then I can just copy volumes over under test13-pre3 and destroy and recreate the first volume group.
Quoted 9 lines
Is it possible you had a snapshot in the volume group when you started lvm 0.9 the first time? snapshots are not persistent on pre3 so it doesn't make sense to left them before rebooting the kernel, and maybe lvmtools 0.9 doesn't cope correctly with non persistent snapshot created by 0.8 driver (trivial to temporarly workaround, just delete any snapshot volume before using 0.9 lvm :).
Andrea
**********************************************************************
This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
**********************************************************************
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
I've been on vacation....
Nope, no snapshots.
Well, I couldn't get my orginal volume group visible under both lvm 0.8 and 0.9. I don't know why. So I grabbed a big empty hard disk, created a new volume group that was visible under both, dded all the logical volumes over to it, updated fstab and removed the offending vg. I've yet to recreate the original vg, copy stuff back and remove the new drive. I should point out that the offending vg was relatively ancient, I think I created it when 0.7 was king under some something like 2.2.14. Now I'm running 2.4.0-ac4 and all works well.
Quoted 13 lines
Date: Wed, 27 Dec 2000 20:53:36 +0100
From: Andrea Arcangeli <[email protected]>
Cc: [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.ascQuoted 3 lines · Todd M. Roy
group is visible, and you just told meit should be, then I can just copy volumes over under test13-pre3 and destroy and recreate the first volume group.
Quoted 9 lines
Is it possible you had a snapshot in the volume group when you started lvm 0.9 the first time? snapshots are not persistent on pre3 so it doesn't make sense to left them before rebooting the kernel, and maybe lvmtools 0.9 doesn't cope correctly with non persistent snapshot created by 0.8 driver (trivial to temporarly workaround, just delete any snapshot volume before using 0.9 lvm :).
Andrea
**********************************************************************
This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
**********************************************************************
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Todd M. Roy
I've been on vacation....
Nope, no snapshots.
Quoted 8 lines
Well, I couldn't get my orginal volume group visible under both lvm 0.8 and 0.9. I don't know why. So I grabbed a big empty hard disk, created a new volume group that was visible under both, dded all the logical volumes over to it, updated fstab and removed the offending vg. I've yet to recreate the original vg, copy stuff back and remove the new drive. I should point out that the offending vg was relatively ancient, I think I created it when 0.7 was king under some something like 2.2.14. Now I'm running 2.4.0-ac4 and all works well.
Good. You may consider to also apply this kernel-driver bugfix for online extent/reduce of the VG and other assorted fixes:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0ac2/lvm-fix-1
I sumbitted them to Heinz a few days ago so that he can merge them with Linus.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
lvm 0.9.1-beta1 still segfaults vgexport
In reply to Todd M. RoyAndrea,
Sorry to say but lvm 0.9.1-beta1 still segfaults
at the same place, line 140 of pv_read_all_pv_of_vg.c pv_this is still null.
This with a straight 2.4.0 kernel with an onstream tape patch and the generated lvm patch. Lvm is a module (on my home machine).
-- todd --
gdb /sbin/vgexport core:
...
#0 0x400427f3 in pv_read_all_pv_of_vg (vg_name=0xbffff794 "vg01PV_EXP",
pv=0xbffff710, reread=0) at pv_read_all_pv_of_vg.c:140
140 for ( p = 0; pv_this[p] != NULL; p++) {
(gdb) print pv_this
$1 = (pv_v2_t **) 0x0
(gdb) bt
#0 0x400427f3 in pv_read_all_pv_of_vg (vg_name=0xbffff794 "vg01PV_EXP",
pv=0xbffff710, reread=0) at pv_read_all_pv_of_vg.c:140
#1 0x400487af in vg_read (vg_name=0xbffff794 "vg01PV_EXP",
vg=0xbffff750)
at vg_read.c:61
#2 0x4004733d in vg_check_exist (vg_name=0xbffff794 "vg01PV_EXP")
at vg_check_exist.c:54
#3 0x80491ee in main (argc=2, argv=0xbffff8cc) at vgexport.c:182
#4 0x4007b213 in __libc_start_main (main=0x8048d00 <main>, argc=2,
ubp_av=0xbffff8cc, init=0x80489c4 <_init>, fini=0x80495b4 <_fini>,
rtld_fini=0x4000d660 <_dl_fini>, stack_end=0xbffff8c4)
at ../sysdeps/generic/libc-start.c:129...
**********************************************************************
This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
**********************************************************************
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: lvm 0.9.1-beta1 still segfaults vgexport
In reply to Todd M. RoyQuoted 4 lines · Todd M. Roy
Andrea,
Sorry to say but lvm 0.9.1-beta1 still segfaults
at the same place, line 140 ofpv_read_all_pv_of_vg.cpv_thisis still null.
BTW, I can easily reproduce. I was near to go into it yesterday but got interrupted by other issues (like the merging of the 0.9.1-beta1 kernel driver and extraction of the strictly necessary fixes from the 0.9.1-beta1 userspace against 0.9).
In the meantime here is the diff between my current kernel lvm driver and 0.9.1-beta1 applied on top of 2.4.1-pre3, Heinz could you merge the below incremental fixes into your tree before merging with Linus? Thanks!
Documentation/Configure.help +0 -9
@@ -1450,15 +1450,6 @@ want), say M here and read Documentation/modules.txt. The module will be called lvm-mod.o. -Logical Volume Manager /proc file system information -CONFIG_LVM_PROC_FS - If you say Y here, you are able to access overall Logical Volume - Manager, Volume Group, Logical and Physical Volume information in - /proc/lvm. - - To use this option, you have to check, that the "/proc file system - support" (CONFIG_PROC_FS) is enabled too. - Multiple devices driver support CONFIG_BLK_DEV_MD This driver lets you combine several hard disk partitions into one
Binary files 2.4.1pre3-lvm-0.9.1_beta1/ID and 2.4.1pre3-lvm-aa/ID differ
drivers/block/ll_rw_blk.c +0 -5
@@ -38,8 +38,6 @@extern int mac_floppy_init (void );#endif -extern int lvm_init (void ); -/* * For the allocated request tables */
@@ -1267,9 +1265,6 @@#endif #ifdef CONFIG_SUN_JSFLASH jsfd_init (); -#endif -#ifdef CONFIG_BLK_DEV_LVM -lvm_init ();#endif return 0 ; };
drivers/md/lvm-snap.c +1 -8
@@ -42,10 +42,6 @@ static char *lvm_snap_version __attribute__ ((unused)) = "LVM 0.9 snapshot code (13/11/2000)\n"; -#ifndef LockPage -#define LockPage (map) set_bit(PG_locked, &(map)->flags) -#endif -extern const char *const lvm_name;extern int lvm_blocksizes[];
@@ -469,7 +465,7 @@ goto out; err = -ENOMEM ; - iobuf->locked =1 ; + iobuf->locked =0 ; iobuf->nr_pages =0 ;for (i =0 ; i < nr_pages; i++) {
@@ -480,9 +476,6 @@ goto out; iobuf->maplist[i] = page; -/* the only point to lock the page here is to be allowed -to share unmap_kiobuf() in the fail-path */ -LockPage (page); iobuf->nr_pages++; } iobuf->offset =0 ;
drivers/md/lvm.c +50 -49
184 lines not on this page · raw message
include/linux/lvm.h +2 -0
@@ -58,6 +58,8 @@* 26/06/2000 - implemented snapshot persistency and resizing support * 02/11/2000 - added hash table size member to lv structure * 12/11/2000 - removed unneeded timestamp definitions +* 24/12/2000 - removed LVM_TO_{CORE,DISK}*, use cpu_{from, to}_le* +* instead - Christoph Hellwig * */
downloadable from here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/lvm/kernel-2.4.1pre3-0.9.1_beta1-fixes-1
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: [lvm-devel] Re: lvm 0.9.1-beta1 still segfaults vgexport
In reply to Todd M. RoyQuoted 4 lines · Andrea Arcangeli
BTW, I can easily reproduce. I was near to go into it yesterday but got interrupted by other issues (like the merging of the 0.9.1-beta1 kernel driver and extraction of the strictly necessary fixes from the 0.9.1-beta1 userspace against 0.9).
This looks the right fix for the vgexport segfault trivially reproducible on 0.9 and 0.9.1_beta1 lvmtools. Now that I see the details of the bug it was possible to reproduce it also with `vgdisplay -D xxxxxxx' where xxxxxxx is just a random name of a not existent VG.
tools/lib/pv_read_all_pv_of_vg.c renamed from tools/lib/pv_read_all_pv_of_vg.c.~1~ +5 -0
@@ -137,6 +137,11 @@while ( pv_this[np] !=NULL ) np++; } +if ( np ==0 ) { + ret = -LVM_EPV_READ_ALL_PV_OF_VG_NP ; + goto pv_read_all_pv_of_vg_end; + } +/* avoid multiple access pathes */ for ( p =0 ; pv_this[p] !=NULL ; p++) {/* avoid multiple access pathes for now (2.4.0-test8)
I also got a reminder from Marco d'Itri to integrate this hack for some more non-x86 platform:
tools/lib/pv_get_size.c renamed from tools/lib/pv_get_size.c.~1~ +1 -1
@@ -58,7 +58,7 @@#define read_le (x) (x)#endif -#if !defined(__alpha__) && !defined(__s390__) +#ifdef __i386__int pv_get_size (char *dev_name,struct partition *part_ptr) {int i =0 ;int dir_cache_count =0 ;
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: [lvm-devel] Re: lvm 0.9.1-beta1 still segfaults vgexport
In reply to Todd M. RoyAndrea,
This worked for me on my home machine!!
Thank you!
-- todd --
Quoted 42 lines · Andrea Arcangeli
Quoted 4 lines · Andrea Arcangeli
BTW, I can easily reproduce. I was near to go into it yesterday but got interrupted by other issues (like the merging of the 0.9.1-beta1 kernel driver and extraction of the strictly necessary fixes from the 0.9.1-beta1 userspace against 0.9).
This looks the right fix for the vgexport segfault trivially reproducible on 0.9 and 0.9.1_beta1 lvmtools. Now that I see the details of the bug it was possible to reproduce it also with `vgdisplay -D xxxxxxx' where xxxxxxx is just a random name of a not existent VG.
tools/lib/pv_read_all_pv_of_vg.c Mon Jan 15 04:57:00 2001 renamed from tools/lib/pv_read_all_pv_of_vg.c.~1~ Mon Jan 15 03:35:51 2001 +5
-0@@ -137,6 +137,11 @@ while ( pv_this[np] != NULL) np++; } + if ( np == 0) { + ret = -LVM_EPV_READ_ALL_PV_OF_VG_NP; + goto pv_read_all_pv_of_vg_end; + } + /* avoid multiple access pathes */ for ( p = 0; pv_this[p] != NULL; p++) { /* avoid multiple access pathes for now (2.4.0-test8)I also got a reminder from Marco d'Itri to integrate this hack for some more non-x86 platform:
tools/lib/pv_get_size.c Mon Jan 15 04:04:03 2001 renamed from tools/lib/pv_get_size.c.~1~ Mon Jan 15 03:35:51 2001 +1
-1@@ -58,7 +58,7 @@ #define read_le(x) (x) #endif -#if !defined(__alpha__) && !defined(__s390__) +#ifdef __i386__ int pv_get_size ( char *dev_name, struct partition *part_ptr) { int i = 0; int dir_cache_count = 0;
Quoted 1 line
Andrea
**********************************************************************
This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
**********************************************************************
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/