[linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

   <http://www.sistina.com/>

for download (Follow the "LVM download page" link).


This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for further information.

We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
patch to Linus.

Please test and feed back related information to <linux-lvm@sistina.com>.

Thanks a lot for your support of LVM.

-- 

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
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Jan Niehusmann]

On Sat, Jan 13, 2001 at 01:15:32AM +0000, Heinz J. Mauelshagen wrote:
> We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
> patch to Linus.

It still has the problem I reported on Dec 22. On Dec 23 I wrote:

: Ok, I found the problem: The sort order of the pv's is wrong, and 0.9 is
: missing the code that sorts them. 0.8final's pv_read_all_pv_of_vg.c contains
: 
:       for ( p = 0; pv_tmp[p] != NULL; p++) {
:          if ( strcmp ( pv_tmp[p]->vg_name, vg_name) == 0) {
:             pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
:             np++;
:          }
:       }
: 
: and 0.9's doesn't.

Jan

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Holger Grothe]

On Sat, Jan 13, 2001 at 05:04:08PM +0100, Jan Niehusmann wrote:
> On Sat, Jan 13, 2001 at 01:15:32AM +0000, Heinz J. Mauelshagen wrote:
> > We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
> > patch to Linus.
> 
> It still has the problem I reported on Dec 22. On Dec 23 I wrote:
> 
> : Ok, I found the problem: The sort order of the pv's is wrong, and 0.9 is
> : missing the code that sorts them. 0.8final's pv_read_all_pv_of_vg.c contains
> : 
> :       for ( p = 0; pv_tmp[p] != NULL; p++) {
> :          if ( strcmp ( pv_tmp[p]->vg_name, vg_name) == 0) {
> :             pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
> :             np++;
> :          }
> :       }
> : 
> : and 0.9's doesn't.

You can see the problem Jan mentioned very easily.

# pvcreate /dev/hda2 /dev/hdc2
pvcreate -- physical volume "/dev/hda2" successfully created
pvcreate -- physical volume "/dev/hdc2" successfully created
# vgcreate vg00 /dev/hda2 /dev/hdc2
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "vg00"
vgcreate -- volume group "vg00" successfully created and activated
# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "vg00"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group

All is fine. But if vg00 is created with 

# vgcreate vg00 /dev/hdc2 /dev/hda2
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "vg00"
vgcreate -- volume group "vg00" successfully created and activated
# vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "vg00"
vgscan -- ERROR "pv_check_consistency_all_pv(): PE" volume group "vg00" is inconsistent
vgscan -- ERROR: unable to do a backup of volume group "vg00"
vgscan -- ERROR "lvm_tab_vg_remove(): unlink" removing volume group "vg00" from "/etc/lvmtab"
vgscan -- ERROR "lvm_tab_vg_remove(): unlink" creating "/etc/lvmtab" and "/etc/lvmtab.d

The following patch from Jan (with a minor correction "against" segfaults :-)
corrected the problem for me:
------------------------------------------------------------------------------
*** pv_read_all_pv_of_vg.c.orig	Mon Nov 20 03:47:20 2000
--- pv_read_all_pv_of_vg.c.patched	Sat Jan 13 18:31:00 2001
***************
*** 101,117 ****
        for ( p = 0; pv_tmp[p] != NULL; p++) {
           if ( strncmp ( pv_tmp[p]->vg_name, vg_name, NAME_LEN) == 0) {
              pv_this_sav = pv_this;
              if ( ( pv_this = realloc ( pv_this,
!                                        ( np + 2) * sizeof ( pv_t*))) == NULL) {
                 fprintf ( stderr, "realloc error in %s [line %d]\n",
                                   __FILE__, __LINE__);
                 ret = -LVM_EPV_READ_ALL_PV_OF_VG_MALLOC;
                 if ( pv_this_sav != NULL) free ( pv_this_sav);
                 goto pv_read_all_pv_of_vg_end;
              }
!             pv_this[np] = pv_tmp[p];
!             pv_this[np+1] = NULL;
!             np++;
           }
        }
  
--- 101,117 ----
        for ( p = 0; pv_tmp[p] != NULL; p++) {
           if ( strncmp ( pv_tmp[p]->vg_name, vg_name, NAME_LEN) == 0) {
              pv_this_sav = pv_this;
+ 	    if ( np < pv_tmp[p]->pv_number) np = pv_tmp[p]->pv_number;
              if ( ( pv_this = realloc ( pv_this,
!                                        ( np + 1) * sizeof ( pv_t*))) == NULL) {
                 fprintf ( stderr, "realloc error in %s [line %d]\n",
                                   __FILE__, __LINE__);
                 ret = -LVM_EPV_READ_ALL_PV_OF_VG_MALLOC;
                 if ( pv_this_sav != NULL) free ( pv_this_sav);
                 goto pv_read_all_pv_of_vg_end;
              }
! 	    pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
!             pv_this[np] = NULL;
           }
        }
  
------------------------------------------------------------------------------

HTH, Holger
-- 
Holger Grothe  (Email: grothe@mathematik.tu-darmstadt.de)
Fachbereich Mathematik, TU Darmstadt

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Holger Grothe]

On Sat, Jan 13, 2001 at 07:08:10PM +0100, Holger Grothe wrote:
[...]
> You can see the problem Jan mentioned very easily.

I hate to followup myself but I forgot to mention:
stock kernel 2.2.18 (+ reiserfs-Patch)

Holger
-- 
Holger Grothe  (Email: grothe@mathematik.tu-darmstadt.de)
Fachbereich Mathematik, TU Darmstadt

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[William L. Jones]

Please fix this problem.  I just a hour banging my head the wall tring to track
down this problem.    It really can trip you up.

Bill Jones



At 07:08 PM 1/13/01 +0100, Holger Grothe wrote:
>On Sat, Jan 13, 2001 at 05:04:08PM +0100, Jan Niehusmann wrote:
> > On Sat, Jan 13, 2001 at 01:15:32AM +0000, Heinz J. Mauelshagen wrote:
> > > We'ld appreciate a couple of days for test feedback before pushing a 
> 2.4.0
> > > patch to Linus.
> >
> > It still has the problem I reported on Dec 22. On Dec 23 I wrote:
> >
> > : Ok, I found the problem: The sort order of the pv's is wrong, and 0.9 is
> > : missing the code that sorts them. 0.8final's pv_read_all_pv_of_vg.c 
> contains
> > :
> > :       for ( p = 0; pv_tmp[p] != NULL; p++) {
> > :          if ( strcmp ( pv_tmp[p]->vg_name, vg_name) == 0) {
> > :             pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
> > :             np++;
> > :          }
> > :       }
> > :
> > : and 0.9's doesn't.
>
>You can see the problem Jan mentioned very easily.
>
># pvcreate /dev/hda2 /dev/hdc2
>pvcreate -- physical volume "/dev/hda2" successfully created
>pvcreate -- physical volume "/dev/hdc2" successfully created
># vgcreate vg00 /dev/hda2 /dev/hdc2
>vgcreate -- INFO: using default physical extent size 4 MB
>vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
>vgcreate -- doing automatic backup of volume group "vg00"
>vgcreate -- volume group "vg00" successfully created and activated
># vgscan
>vgscan -- reading all physical volumes (this may take a while...)
>vgscan -- found active volume group "vg00"
>vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
>vgscan -- WARNING: This program does not do a VGDA backup of your volume group
>
>All is fine. But if vg00 is created with
>
># vgcreate vg00 /dev/hdc2 /dev/hda2
>vgcreate -- INFO: using default physical extent size 4 MB
>vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
>vgcreate -- doing automatic backup of volume group "vg00"
>vgcreate -- volume group "vg00" successfully created and activated
># vgscan
>vgscan -- reading all physical volumes (this may take a while...)
>vgscan -- found active volume group "vg00"
>vgscan -- ERROR "pv_check_consistency_all_pv(): PE" volume group "vg00" is 
>inconsistent
>vgscan -- ERROR: unable to do a backup of volume group "vg00"
>vgscan -- ERROR "lvm_tab_vg_remove(): unlink" removing volume group "vg00" 
>from "/etc/lvmtab"
>vgscan -- ERROR "lvm_tab_vg_remove(): unlink" creating "/etc/lvmtab" and 
>"/etc/lvmtab.d
>
>The following patch from Jan (with a minor correction "against" segfaults :-)
>corrected the problem for me:
>------------------------------------------------------------------------------
>*** pv_read_all_pv_of_vg.c.orig Mon Nov 20 03:47:20 2000
>--- pv_read_all_pv_of_vg.c.patched      Sat Jan 13 18:31:00 2001
>***************
>*** 101,117 ****
>         for ( p = 0; pv_tmp[p] != NULL; p++) {
>            if ( strncmp ( pv_tmp[p]->vg_name, vg_name, NAME_LEN) == 0) {
>               pv_this_sav = pv_this;
>               if ( ( pv_this = realloc ( pv_this,
>!                                        ( np + 2) * sizeof ( pv_t*))) == 
>NULL) {
>                  fprintf ( stderr, "realloc error in %s [line %d]\n",
>                                    __FILE__, __LINE__);
>                  ret = -LVM_EPV_READ_ALL_PV_OF_VG_MALLOC;
>                  if ( pv_this_sav != NULL) free ( pv_this_sav);
>                  goto pv_read_all_pv_of_vg_end;
>               }
>!             pv_this[np] = pv_tmp[p];
>!             pv_this[np+1] = NULL;
>!             np++;
>            }
>         }
>
>--- 101,117 ----
>         for ( p = 0; pv_tmp[p] != NULL; p++) {
>            if ( strncmp ( pv_tmp[p]->vg_name, vg_name, NAME_LEN) == 0) {
>               pv_this_sav = pv_this;
>+           if ( np < pv_tmp[p]->pv_number) np = pv_tmp[p]->pv_number;
>               if ( ( pv_this = realloc ( pv_this,
>!                                        ( np + 1) * sizeof ( pv_t*))) == 
>NULL) {
>                  fprintf ( stderr, "realloc error in %s [line %d]\n",
>                                    __FILE__, __LINE__);
>                  ret = -LVM_EPV_READ_ALL_PV_OF_VG_MALLOC;
>                  if ( pv_this_sav != NULL) free ( pv_this_sav);
>                  goto pv_read_all_pv_of_vg_end;
>               }
>!           pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
>!             pv_this[np] = NULL;
>            }
>         }
>
>------------------------------------------------------------------------------
>
>HTH, Holger
>--
>Holger Grothe  (Email: grothe@mathematik.tu-darmstadt.de)
>Fachbereich Mathematik, TU Darmstadt
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@sistina.com
>http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Rob Fugina]

On Sat, Jan 13, 2001 at 05:04:08PM +0100, Jan Niehusmann wrote:
> On Sat, Jan 13, 2001 at 01:15:32AM +0000, Heinz J. Mauelshagen wrote:
> > We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
> > patch to Linus.
> 
> It still has the problem I reported on Dec 22. On Dec 23 I wrote:
> 
> : Ok, I found the problem: The sort order of the pv's is wrong, and 0.9 is
> : missing the code that sorts them. 0.8final's pv_read_all_pv_of_vg.c contains
> : 
> :       for ( p = 0; pv_tmp[p] != NULL; p++) {
> :          if ( strcmp ( pv_tmp[p]->vg_name, vg_name) == 0) {
> :             pv_this[pv_tmp[p]->pv_number-1] = pv_tmp[p];
> :             np++;
> :          }
> :       }
> : 
> : and 0.9's doesn't.

I wonder if this is why I lost all of my data last Thursday...

vg w/ 2 pv's (hde1 & hdg1) and 3 lv's.  Add a pv (hdc1) and
reboot, and all of a sudden, even though the vg is still there,
with 3 pv's and 3 lv's, the lv's won't even fsck (bad magic
number in superblock -- doesn't even look like a filesystem was
even there).  I though maybe it had a problem w/ rearranging the
pv's or something...  How else could it completely lose track
of my data?

It was kernel 2.4.0 w/ the several-line vg_extend patch, and the 0.9
tools...

Oh, well -- just a WAG...

Rob

-- 
Rob Fugina, Systems Guy
robf@geekthing.com -- http://www.geekthing.com
My firewall filters MS Office attachments.

               Mud is not one of the four food groups.

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Steven Lembark]

> I wonder if this is why I lost all of my data last Thursday...
> 
> vg w/ 2 pv's (hde1 & hdg1) and 3 lv's.  Add a pv (hdc1) and
> reboot, and all of a sudden, even though the vg is still there,
> with 3 pv's and 3 lv's, the lv's won't even fsck (bad magic
> number in superblock -- doesn't even look like a filesystem was
> even there).  I though maybe it had a problem w/ rearranging the
> pv's or something...  How else could it completely lose track
> of my data?
> 
> It was kernel 2.4.0 w/ the several-line vg_extend patch, and the 0.9
> tools...

you probably hadn't lost anything.  one approach that usually
works is to:

	vgexport vg0;
	vgimport vg0 /first/disk /second/disk;

likely to get you back to where you were before the vgextend.

if vgimport doesn't like them anymore you can create a new lv,
vgextend it to the two devices and create new vg's w/ the same
allocations as the old ones (simple enough if they havn't been
extended too many times).

-- 
 Steven Lembark                                   2930 W. Palmer St.
                                                 Chicago, IL  60647
 lembark@wrkhors.com                                   800-762-1582

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Jan Niehusmann]

On Sat, Jan 13, 2001 at 01:15:32AM +0000, Heinz J. Mauelshagen wrote:
> a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

Is it intentional that lvm 0.9.1 builds liblvm-0.9.0 ?

Jan

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Jan Niehusmann]

Another thing with 0.9.1 - or to be exact, 0.9.1 userlevel tools
with the pv order patch, and a 2.4.1-pre3 kernel 
(didn't test with other versions):


I issued the following commands:

pvmove /dev/sda2
vgreduce vg1 /dev/sda2
vgscan

(You guess it - I just removed an old scsi drive from my VG)

Afterwards I wanted to see if everything was OK and did a vgdisplay -v:

--- Volume group ---
VG Name               vg1
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                23
Open LV               20
MAX LV Size           1023.97 GB
Max PV                256
Cur PV                1
Act PV                1
VG Size               72.95 GB
PE Size               16 MB
Total PE              4669
Alloc PE / Size       3217 / 50.27 GB
Free  PE / Size       1452 / 22.69 GB
VG UUID               5HozPs-vN3u-eT3i-LNQp-eAE0-8HIS-KPy1O7

--- Logical volume ---
[...]

--- Physical volumes ---
PV Name (#)           /dev/hda5 (1)
PV Status             available / allocatable
Total PE / Free PE    414 / 0


Uh, what? Only one PV? Where is the other one, /dev/hdc4 with 4447 PEs?
But the system still works well, and vgdisplay -D shows all the PVs.
So I just rebooted and now everything is fine again. 

Any idea what may have caused that behaviour?


Jan