RE: [linux-lvm] Problem using lvreduce

RE: [linux-lvm] Problem using lvreduce

[Soohoon Lee]

That's the problem what I had.
I posted fix and waiting verification but 
mail traffic saying they are busy with 1.0 release and PE start point
problem.
And seems, this problem is also related to that PE start point problem.
Anyway, quick and no warranty fix is


--- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
+++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
@@ -85,7 +85,7 @@
          }
          pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
                       LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
-                      vg->pe_size;
+                      vg->pe_size - 1;
          debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector: %lu\n",
                   vg->pv[pv_num]->pv_name,
                   pe_index,



-----Original Message-----
From: Faux Pas III [mailto:fauxpas@trellisinc.com]
Sent: Wednesday, August 15, 2001 7:50 PM
To: linux-lvm@sistina.com
Subject: [linux-lvm] Problem using lvreduce


I have been having a problem removing a drive from a running 
volume group.  I repeat this by creating a volume group from
/dev/sda, /dev/sdb (each 18gb), /dev/hde, and /dev/hdg (each
30gb).  I create an LV that spans all physical extents in 
this group.  I then try to use lvreduce to take 4400 PE's out
of the group (slightly more than occupy either of the two 
scsi drives).

Gryphon:~# lvreduce -l -4400 /dev/test_vg/test_lv 
lvreduce -- WARNING: reducing active logical volume to 72.62 GB
lvreduce -- THIS MAY DESTROY YOUR DATA (filesystem etc.)
lvreduce -- do you really want to reduce "/dev/test_vg/test_lv"? [y/n]: y
lvreduce -- ERROR "pv_check_consistency_all_pv(): PE" volume group "test_vg"
is inconsistent
lvreduce -- WARNING: you don't have an automatic backup of "test_vg"
lvreduce -- logical volume "/dev/test_vg/test_lv" successfully reduced

After this, all manner of badness ensues, including:

Gryphon:~# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run
vgscan

In any event, I'm not able to pvmove or vgreduce to get the drive out of
the volume group as I would expect.   This is on 2.4.8 + LVM 1.0, and also
manifests on 2.4.7 + LVM 0.9.1beta8.  I can provide any other diagnostic
info that would be helpful, as I can reproduce this problem easily.

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.
_______________________________________________
linux-lvm mailing list
linux-lvm@sistina.com
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

Re: [linux-lvm] Problem using lvreduce

[Faux Pas III]

On Thu, Aug 16, 2001 at 01:06:39PM -0400, Soohoon Lee wrote:

> I posted fix and waiting verification but 
> mail traffic saying they are busy with 1.0 release and PE start point
> Anyway, quick and no warranty fix is

<snip patch>

Looks like that did it, I'm going to test it more aggressively but 
everything worked the first time through.  Thanks !

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.

Re: [linux-lvm] Problem using lvreduce

[Joe Thornber]

Soohoon,

On Thu, Aug 16, 2001 at 01:06:39PM -0400, Soohoon Lee wrote:
> 
> That's the problem what I had.
> I posted fix and waiting verification but 
> mail traffic saying they are busy with 1.0 release and PE start point
> problem.

If you think we're not attending something important, please repost
and kick up a fuss.  I do forget/miss things on the list.

> And seems, this problem is also related to that PE start point problem.
> Anyway, quick and no warranty fix is
> 
> 
> --- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
> +++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
> @@ -85,7 +85,7 @@
>           }
>           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
>                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
> -                      vg->pe_size;
> +                      vg->pe_size - 1;
>           debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector: %lu\n",
>                    vg->pv[pv_num]->pv_name,
>                    pe_index,


This patch looks wrong, I cant see why anyone would want to divide by
pe_size - 1, if it's working it's by accident.

I'm not familiar with this bit of code, but what I think it's doing
is converting the le number 'p' into a pe number.  I suspect that for your
system the le numbers map directly onto the pe numbers, hence your comment
wondering why we don't just use 'p'.  The pe location changed recently so
I could well believe this calculation is wrong.

Heinz, 

Please confirm this is what this bit of code does.

If so we should introduce a companion for get_pe_offset that does the
opposite in liblvm.h:

static inline ulong get_pe_from_offset(ulong offset, pv_t *pv)
{
	return (offset - pv->pe_start) / pv->pe_size;
}

- Joe

Re: [linux-lvm] Problem using lvreduce

[Goetz Bock]

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


On Fri, Aug 17 '01 at 11:43, Joe Thornber wrote:
> > --- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
> > +++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
> > @@ -85,7 +85,7 @@
> >           }
> >           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
> >                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
> > -                      vg->pe_size;
> > +                      vg->pe_size - 1;
> >           debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector: %lu\n",
> >                    vg->pv[pv_num]->pv_name,
> >                    pe_index,
> 
> This patch looks wrong, I cant see why anyone would want to divide by
> pe_size - 1, if it's working it's by accident.
Disclamer: I did not lok at the code, and don't know what IŠm talking
           about ...

But, what this patch does, is devide by pe_size and substract 1 from the
result.
-- 
Goetz Bock                                              IT Consultant
Dipl.-Inf. Univ.

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

Re: [linux-lvm] Problem using lvreduce

[Joe Thornber]

On Fri, Aug 17, 2001 at 03:05:40PM +0200, Goetz Bock wrote:
> 
> On Fri, Aug 17 '01 at 11:43, Joe Thornber wrote:
> > > --- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
> > > +++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
> > > @@ -85,7 +85,7 @@
> > >           }
> > >           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
> > >                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
> > > -                      vg->pe_size;
> > > +                      vg->pe_size - 1;
> > >           debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector: %lu\n",
> > >                    vg->pv[pv_num]->pv_name,
> > >                    pe_index,
> > 
> > This patch looks wrong, I cant see why anyone would want to divide by
> > pe_size - 1, if it's working it's by accident.
> Disclamer: I did not lok at the code, and don't know what I
m talking
>            about ...
> 
> But, what this patch does, is devide by pe_size and substract 1 from the
> result.

doh, parse error !

Still wrong.

- Joe

Re: [linux-lvm] Problem using lvreduce

[Heinz J . Mauelshagen]

On Fri, Aug 17, 2001 at 11:43:44AM +0100, Joe Thornber wrote:
> Soohoon,
> 
> On Thu, Aug 16, 2001 at 01:06:39PM -0400, Soohoon Lee wrote:
> > 
> > That's the problem what I had.
> > I posted fix and waiting verification but 
> > mail traffic saying they are busy with 1.0 release and PE start point
> > problem.
> 
> If you think we're not attending something important, please repost
> and kick up a fuss.  I do forget/miss things on the list.
> 
> > And seems, this problem is also related to that PE start point problem.
> > Anyway, quick and no warranty fix is
> > 
> > 
> > --- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
> > +++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
> > @@ -85,7 +85,7 @@
> >           }
> >           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
> >                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
> > -                      vg->pe_size;
> > +                      vg->pe_size - 1;
> >           debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector: %lu\n",
> >                    vg->pv[pv_num]->pv_name,
> >                    pe_index,
> 
> 
> This patch looks wrong, I cant see why anyone would want to divide by
> pe_size - 1, if it's working it's by accident.
> 
> I'm not familiar with this bit of code, but what I think it's doing
> is converting the le number 'p' into a pe number.
> I suspect that for your
> system the le numbers map directly onto the pe numbers, hence your comment
> wondering why we don't just use 'p'.  The pe location changed recently so
> I could well believe this calculation is wrong.
> 
> Heinz, 
> 
> Please confirm this is what this bit of code does.

Yes, a pe index in the range of 0 to n.
With the patch that will well result in -1 to n-1, wich is wrong.

> 
> If so we should introduce a companion for get_pe_offset that does the
> opposite in liblvm.h:
> 
> static inline ulong get_pe_from_offset(ulong offset, pv_t *pv)
> {
> 	return (offset - pv->pe_start) / pv->pe_size;
> }
> 
> - Joe
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

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] Problem using lvreduce

[Faux Pas III]

On Fri, Aug 17, 2001 at 04:38:31PM +0200, Heinz J . Mauelshagen wrote:
 
> Yes, a pe index in the range of 0 to n.
> With the patch that will well result in -1 to n-1, wich is wrong.

Since it seems settled that this patch is the Wrong Way, is there a 
proper patch that addresses the problem that I can grab ?

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.

Re: [linux-lvm] Problem using lvreduce

[Joe Thornber]

On Fri, Aug 17, 2001 at 11:41:43AM -0400, Faux Pas III wrote:
> On Fri, Aug 17, 2001 at 04:38:31PM +0200, Heinz J . Mauelshagen wrote:
>  
> > Yes, a pe index in the range of 0 to n.
> > With the patch that will well result in -1 to n-1, wich is wrong.
> 
> Since it seems settled that this patch is the Wrong Way, is there a 
> proper patch that addresses the problem that I can grab ?

Grab 1.0.1-rc1, please mail me how you get on.

- Joe

Re: [linux-lvm] Problem using lvreduce

[Faux Pas III]

On Sat, Aug 18, 2001 at 11:04:42AM +0100, Joe Thornber wrote:
 
> Grab 1.0.1-rc1, please mail me how you get on.

I'm using 2.4.9 + ext3 + lvm 1.0.1rc1, and everything seems 
solid; I've done quite a bit of resizing and shuffling PE's 
around and my data is still intact.  Thanks ! 

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.

RE: [linux-lvm] Problem using lvreduce

[Soohoon Lee]

Well, got attentions!
Thanks.

Actually I don't know well LVM.
I've been using this for two weeks so far
So if you say it's wrong then it'll be wrong but to get
real fix, I like to tell you what I had.
First of all, lvreduce/lvextend doesn't work. It's very easly reprodusable.
And I found that problem is when it releases PEs,
Let's say a VG has 0-9 PEs and going to release half of them,
It releases 6-10! and seems origin of that mis calculation is the formular.
           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
                        vg->pe_size;
If I replace variables to real values for PE[0]
	   1        =  (8352 -
                              81920 / 512) /
                              8192;
I don't know which value is wrong but what I needed to get was -1 of the
result.
And it worked, I tried create/reduce/extend many times to have multiple VGs
fragmented
but it still works.
So I could tell, -1 wouldn't be a real fix but problem is very close to
that.

Soohoon.


-----Original Message-----
From: Heinz J . Mauelshagen [mailto:mauelshagen@sistina.com]
Sent: Friday, August 17, 2001 10:39 AM
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Problem using lvreduce


On Fri, Aug 17, 2001 at 11:43:44AM +0100, Joe Thornber wrote:
> Soohoon,
> 
> On Thu, Aug 16, 2001 at 01:06:39PM -0400, Soohoon Lee wrote:
> > 
> > That's the problem what I had.
> > I posted fix and waiting verification but 
> > mail traffic saying they are busy with 1.0 release and PE start point
> > problem.
> 
> If you think we're not attending something important, please repost
> and kick up a fuss.  I do forget/miss things on the list.
> 
> > And seems, this problem is also related to that PE start point problem.
> > Anyway, quick and no warranty fix is
> > 
> > 
> > --- pv_release_pe.c.old Thu Aug 16 09:23:35 2001
> > +++ pv_release_pe.c     Wed Aug 15 09:09:06 2001
> > @@ -85,7 +85,7 @@
> >           }
> >           pe_index = ( vg->lv[l]->lv_current_pe[p].pe - 
> >                        LVM_VGDA_SIZE ( vg->pv[pv_num]) / SECTOR_SIZE) /
> > -                      vg->pe_size;
> > +                      vg->pe_size - 1;
> >           debug ( "pv_release_pe -- pv_name: %s  pe: %lu  sector:
%lu\n",
> >                    vg->pv[pv_num]->pv_name,
> >                    pe_index,
> 
> 
> This patch looks wrong, I cant see why anyone would want to divide by
> pe_size - 1, if it's working it's by accident.
> 
> I'm not familiar with this bit of code, but what I think it's doing
> is converting the le number 'p' into a pe number.
> I suspect that for your
> system the le numbers map directly onto the pe numbers, hence your comment
> wondering why we don't just use 'p'.  The pe location changed recently so
> I could well believe this calculation is wrong.
> 
> Heinz, 
> 
> Please confirm this is what this bit of code does.

Yes, a pe index in the range of 0 to n.
With the patch that will well result in -1 to n-1, wich is wrong.

> 
> If so we should introduce a companion for get_pe_offset that does the
> opposite in liblvm.h:
> 
> static inline ulong get_pe_from_offset(ulong offset, pv_t *pv)
> {
> 	return (offset - pv->pe_start) / pv->pe_size;
> }
> 
> - Joe
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-
_______________________________________________
linux-lvm mailing list
linux-lvm@sistina.com
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

[linux-lvm] Problem using lvreduce

[Faux Pas III]

I have been having a problem removing a drive from a running 
volume group.  I repeat this by creating a volume group from
/dev/sda, /dev/sdb (each 18gb), /dev/hde, and /dev/hdg (each
30gb).  I create an LV that spans all physical extents in 
this group.  I then try to use lvreduce to take 4400 PE's out
of the group (slightly more than occupy either of the two 
scsi drives).

Gryphon:~# lvreduce -l -4400 /dev/test_vg/test_lv 
lvreduce -- WARNING: reducing active logical volume to 72.62 GB
lvreduce -- THIS MAY DESTROY YOUR DATA (filesystem etc.)
lvreduce -- do you really want to reduce "/dev/test_vg/test_lv"? [y/n]: y
lvreduce -- ERROR "pv_check_consistency_all_pv(): PE" volume group "test_vg" is inconsistent
lvreduce -- WARNING: you don't have an automatic backup of "test_vg"
lvreduce -- logical volume "/dev/test_vg/test_lv" successfully reduced

After this, all manner of badness ensues, including:

Gryphon:~# vgdisplay
vgdisplay -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan

In any event, I'm not able to pvmove or vgreduce to get the drive out of
the volume group as I would expect.   This is on 2.4.8 + LVM 1.0, and also
manifests on 2.4.7 + LVM 0.9.1beta8.  I can provide any other diagnostic
info that would be helpful, as I can reproduce this problem easily.

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.