[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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> 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).

Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Would it be possible to clean up the ioctl interface so we dont need
such large hacks for LVM support? I can do the work but I want to be
sure you guys will agree to it.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Andreas Dilger]

Anton, you write:
> Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Yuk.

> Would it be possible to clean up the ioctl interface so we dont need
> such large hacks for LVM support? I can do the work but I want to be
> sure you guys will agree to it.

What is the reason for all this?  Alignment/wordsize/other?  If you look
at the IOP10 code, much of the in-core data structs were changed to int
or long, so this sparc code may not be necessary.  It may in fact be
damaging, because I don't know if any of the LVM developers even know it
is there, and surely it will be out of sync...

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

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Andreas Dilger]

Anton, you write:
> Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Yuk.

> Would it be possible to clean up the ioctl interface so we dont need
> such large hacks for LVM support? I can do the work but I want to be
> sure you guys will agree to it.

What is the reason for all this?  Alignment/wordsize/other?  If you look
at the IOP10 code, much of the in-core data structs were changed to int
or long, so this sparc code may not be necessary.  It may in fact be
damaging, because I don't know if any of the LVM developers even know it
is there, and surely it will be out of sync...

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.  It may in fact be
> damaging, because I don't know if any of the LVM developers even know it
> is there, and surely it will be out of sync...

Two things:

Structures used in ioctls should have explicit sizes (eg u32, not unsigned
long). Remember on sparc64 we have a 32 bit userspace and 64 bit kernel.

Having pointers to other structures is considered bad form again due to the
32bit/64bit differences. Think 32 bit pointers vs 64 bit pointers :)

When either of these happen we have to write up translation code. Of
the two, having pointers to other structs is definitely the worst. 

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> Anton, you write:
> > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> 
> Yuk.
> 
> > Would it be possible to clean up the ioctl interface so we dont need
> > such large hacks for LVM support? I can do the work but I want to be
> > sure you guys will agree to it.
> 
> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.

The longs are the biggest problem AFAICS.
long is 64bit on sparc64 and 32bit on sparc32...

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

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

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> Anton, you write:
> > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> 
> Yuk.
> 
> > Would it be possible to clean up the ioctl interface so we dont need
> > such large hacks for LVM support? I can do the work but I want to be
> > sure you guys will agree to it.
> 
> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.

The longs are the biggest problem AFAICS.
long is 64bit on sparc64 and 32bit on sparc32...

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Anton Blanchard]

 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

Embedding pointers in ioctls is much worse. When this happens we basically
end up duplicating the ioctl parsing code (this code courtesy of jakub's
sharp mind, but it would be nice not to require this :)

Anton

        case VG_CREATE:
                v = kmalloc(sizeof(vg_t), GFP_KERNEL);
                if (!v) return -ENOMEM;
                if (copy_from_user(v, (void *)arg, (long)&((vg32_t *)0)->proc) ||
                    __get_user(v->proc, &((vg32_t *)arg)->proc)) {
                        kfree(v);
                        return -EFAULT;
                }
                karg = v;
                memset(v->pv, 0, sizeof(v->pv) + sizeof(v->lv));
                if (v->pv_max > ABS_MAX_PV || v->lv_max > ABS_MAX_LV)
                        return -EPERM;
                for (i = 0; i < v->pv_max; i++) {
                        err = __get_user(ptr, &((vg32_t *)arg)->pv[i]);
                        if (err) break;
                        if (ptr) {
                                v->pv[i] = kmalloc(sizeof(pv_t), GFP_KERNEL);
                                if (!v->pv[i]) {
                                        err = -ENOMEM;
                                        break;
                                }
                                err = copy_from_user(v->pv[i], (void *)A(ptr), sizeof(pv32_t) - 8);
                                if (err) {
                                        err = -EFAULT;
                                        break;
                                }
                                v->pv[i]->pe = NULL; v->pv[i]->inode = NULL;
                        }
                }
                if (!err) {
                        for (i = 0; i < v->lv_max; i++) {
                                err = __get_user(ptr, &((vg32_t *)arg)->lv[i]);
                                if (err) break;
                                if (ptr) {
                                        v->lv[i] = get_lv_t(ptr, &err);
                                        if (err) break;
                                }
                        }
                }
                break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Patrick Caulfield]

On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > Anton, you write:
> > > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> > 
> > Yuk.
> > 
> > > Would it be possible to clean up the ioctl interface so we dont need
> > > such large hacks for LVM support? I can do the work but I want to be
> > > sure you guys will agree to it.

If you're prepared to do the work we'd be glad to accept the patch - please send
it to me or the list so I can check over it before committing it. As we don't
have an UltraSPARC available for testing it's probably better done by someone
who does !
 
> > What is the reason for all this?  Alignment/wordsize/other?  If you look
> > at the IOP10 code, much of the in-core data structs were changed to int
> > or long, so this sparc code may not be necessary.
> 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

There are still a few ulong members in lvm.h, they should be uint32_t 

patrick

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

[Patrick Caulfield]

On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > Anton, you write:
> > > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> > 
> > Yuk.
> > 
> > > Would it be possible to clean up the ioctl interface so we dont need
> > > such large hacks for LVM support? I can do the work but I want to be
> > > sure you guys will agree to it.

If you're prepared to do the work we'd be glad to accept the patch - please send
it to me or the list so I can check over it before committing it. As we don't
have an UltraSPARC available for testing it's probably better done by someone
who does !
 
> > What is the reason for all this?  Alignment/wordsize/other?  If you look
> > at the IOP10 code, much of the in-core data structs were changed to int
> > or long, so this sparc code may not be necessary.
> 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

There are still a few ulong members in lvm.h, they should be uint32_t 

patrick

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Charles Duffy]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On Tue, Jan 16, 2001 at 08:51:18AM +0000, Patrick Caulfield wrote:
> On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> > On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > > > Would it be possible to clean up the ioctl interface so we
> > > > dont need such large hacks for LVM support? I can do the work
> > > > but I want to be sure you guys will agree to it.
> 
> If you're prepared to do the work we'd be glad to accept the patch -
> please send it to me or the list so I can check over it before
> committing it. As we don't have an UltraSPARC available for testing
> it's probably better done by someone who does !

I have an Ultra-1 available, presently in use as a prototyping system.
It's not currently using LVM and there's no unpartitioned space on the
drive, but if one of the core developers (or otherwise someone I have
reason to trust) wants to try testing LVM over loopback (or something
of that sort), I can provide access.

I don't have the time to do testing myself, unless someone can provide
a specific set of instructions (ie. the nature of an expected bug is
known; the only question is its presence).

Btw, I can only promise availability for about a week or so; the
machine may become a production system after that time.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

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

[Patrick Caulfield]

On Tue, Jan 16, 2001 at 12:10:46PM -0800, Charles Duffy wrote:
> On Tue, Jan 16, 2001 at 08:51:18AM +0000, Patrick Caulfield wrote:
> > On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> > > On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > > > > Would it be possible to clean up the ioctl interface so we
> > > > > dont need such large hacks for LVM support? I can do the work
> > > > > but I want to be sure you guys will agree to it.
> > 
> > If you're prepared to do the work we'd be glad to accept the patch -
> > please send it to me or the list so I can check over it before
> > committing it. As we don't have an UltraSPARC available for testing
> > it's probably better done by someone who does !
> 
> I have an Ultra-1 available, presently in use as a prototyping system.
> It's not currently using LVM and there's no unpartitioned space on the
> drive, but if one of the core developers (or otherwise someone I have
> reason to trust) wants to try testing LVM over loopback (or something
> of that sort), I can provide access.

I was hoping that Anton would volunteer as per his message in linux-kernel :-)

Having looked in (too much) depth at the code I decided I don't know enough
about Ultra-SPARCs to be able to do this on some else's machine. 

I've worked fairly extensively on Alphas (which are a pure 64 bit machine)
but the sparc seems to have some bizarre 32 bit modes I know nothing about.


patrick

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