[linux-lvm] lvextend NEVER works but screws up

[linux-lvm] lvextend NEVER works but screws up

[tariq wali]

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

Hi, i was a big fan of lvm and used to advocate it's use at my workplace
but each time i try to use lvreduce or lvextend on production it has ALWAYS
been a major let down and messed up our production data and caused major
outages and not to forget the big stick up *** .

please look at the sequence and this is what I did

 vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 492.72G     * 42.72G*
*
*
*df -kh*
*/dev/mapper/vg0-logs   99G   43G   52G  46% /bin-logs*
*
*
I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
what I ran in order to extended

# lvextend -L +42.7G -n /dev/vg0/logs
  Rounding up size to full physical extent 42.70 GB
  Extending logical volume logs to 142.70 GB
  Logical volume logs successfully resized

#resize2fs /dev/vg0/logs    ( and it gets screwed up here )
resize2fs 1.39 (29-May-2006)
*resize2fs: Filesystem has unsupported feature(s) while trying to open
/dev/vg0/logs*
*Couldn't find valid filesystem superblock.*
*
*
and the free space of 42.7G is also gone ,

 # vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 492.72G  * 20.00M*
*
*
*
lvm version
  LVM version:     2.02.88(2)-RHEL5 (2012-01-20)
  Library version: 1.02.67-RHEL5 (2011-10-14)
  Driver version:  4.11.6

*
*
*
It' so annoying to see this happen , from what I know that's the cmd
sequence to extend an existing LVM online , now I am not sure what this did
to my filesystem and  hoping it hasn't ****ED my data yet .

your insights would greatly be appreciated .







-- 
*Tariq Wali.*

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]

[linux-lvm] lvextend NEVER works but screws up

[tariq wali]

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

Hi, i was a big fan of lvm and used to advocate it's use at my workplace
but each time i try to use lvreduce or lvextend on production it has ALWAYS
been a major let down and messed up our production data and caused major
outages and not to forget the big stick up *** .

please look at the sequence and this is what I did

 vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 492.72G     * 42.72G*
*
*
*df -kh*
*/dev/mapper/vg0-logs   99G   43G   52G  46% /bin-logs*
*
*
I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
what I ran in order to extended

# lvextend -L +42.7G -n /dev/vg0/logs
  Rounding up size to full physical extent 42.70 GB
  Extending logical volume logs to 142.70 GB
  Logical volume logs successfully resized

#resize2fs /dev/vg0/logs    ( and it gets screwed up here )
resize2fs 1.39 (29-May-2006)
*resize2fs: Filesystem has unsupported feature(s) while trying to open
/dev/vg0/logs*
*Couldn't find valid filesystem superblock.*
*
*
and the free space of 42.7G is also gone ,

 # vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg0    1   2   0 wz--n- 492.72G  * 20.00M*
*
*
*
lvm version
  LVM version:     2.02.88(2)-RHEL5 (2012-01-20)
  Library version: 1.02.67-RHEL5 (2011-10-14)
  Driver version:  4.11.6

*
*
*
It' so annoying to see this happen , from what I know that's the cmd
sequence to extend an existing LVM online , now I am not sure what this did
to my filesystem and  hoping it hasn't ****ED my data yet .

your insights would greatly be appreciated .







-- 
*Tariq Wali.*




-- 
*Tariq Wali.*

[-- Attachment #2: Type: text/html, Size: 2733 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[Vic]

> I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
> what I ran in order to extended
>
> # lvextend -L +42.7G -n /dev/vg0/logs

Well, I usually use lvresize to do this job, but lvextend should be fine.

I wouldn't put that "-n" in, though; mucking around with a filesystem that
needs fscking and not doing so would seem to be asking for trouble...

HTH

Vic.

Re: [linux-lvm] lvextend NEVER works but screws up

[tariq wali]

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

 lvresize to extend an lvm ? how

also I cant create a new lvm don't have that much space and the to extend
the new one and it would mean downtime . don't think it's an issue with
filesystem tools , lvm has NEVER been consistent in my case .

On Thu, Aug 23, 2012 at 7:40 PM, Vic <lvm@beer.org.uk> wrote:

>
> > I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
> > what I ran in order to extended
> >
> > # lvextend -L +42.7G -n /dev/vg0/logs
>
> Well, I usually use lvresize to do this job, but lvextend should be fine.
>
> I wouldn't put that "-n" in, though; mucking around with a filesystem that
> needs fscking and not doing so would seem to be asking for trouble...
>
> HTH
>
> Vic.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>



-- 
*Tariq Wali.*

[-- Attachment #2: Type: text/html, Size: 2148 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[Vic]

>  lvresize to extend an lvm ? how

lvresize -L +size /dev/vg_whatever/lv_thingie
resize2fs /dev/vg_whatever/lv_thingie

> lvm has NEVER been consistent in my case .

LVM has always been consistent in my case, except for the time I tried to
mirror a VG, when it wouldn't start without both halves of the mirror :-(

Vic.

Re: [linux-lvm] lvextend NEVER works but screws up

[Jonathan Tripathy]

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

On 23/08/2012 16:18, tariq wali wrote:
>  lvresize to extend an lvm ? how
It's the same syntax as lvextend.
>
> also I cant create a new lvm don't have that much space and the to 
> extend the new one and it would mean downtime . don't think it's an 
> issue with filesystem tools , lvm has NEVER been consistent in my case .
Can you please provide details on why you don't think it's a filesystem 
issue? Have you come across other details that lead you to believe this? 
These details may help the list in helping you. While I may be over 
simplifying things, all LVM is, is a fancy block mapper. Most 
complicated things are done by the filesystem on top.

[-- Attachment #2: Type: text/html, Size: 1676 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[Stuart D Gathman]

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

On 08/23/2012 11:18 AM, tariq wali wrote:
>  lvresize to extend an lvm ? how
>
> also I cant create a new lvm don't have that much space and the to 
> extend the new one and it would mean downtime . don't think it's an 
> issue with filesystem tools , lvm has NEVER been consistent in my case .
>
The resize2fs on RHEL5 does not support ext4.  Your error message is the 
one reported when you try to resize an ext4 filesystem with ext2/ext3 
tools.  You need to either install e4fsprogrs and use resize4fs (and 
e4fsck), or do the resize in the virtual machine you are apparently 
running a newer OS in.

[-- Attachment #2: Type: text/html, Size: 1473 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[tariq wali]

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

Guys , thanks much for your time on the issue, really appreciate it . I had
tried everything suggested so far (lvresize/extend) updated filesystem
tools etc

@Stuart D Gathman , YOU ARE THE MAN SIR :) and nailed it down .

I wanted to reproduce the same issue again and i did that not know how
ignorant I was being ..

# lvextend -L +40G /dev/vg0/bin-logs
  Extending logical volume bin-logs to 110.00 GB
  Logical volume bin-logs successfully resized


lvs
  LV       VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  bin-logs vg0  -wi-ao *110.00G*
  data     vg0  -wi-ao 380.00G

resize2fs /dev/vg0/bin-logs
resize2fs 1.39 (29-May-2006)
resize2fs: Filesystem has unsupported feature(s) while trying to open
/dev/vg0/bin-logs
Couldn't find valid filesystem superblock.

#this is where I would get psyched , i did the same thing to all my ext2/3
filesystems and have extended file systems online without an issue for
years ..but did I fforget the file system type this time , yes indeed I for
got we have started doing ext4 on all our new servers and didn't realise
ext4 fancies it's own bells and whistles ..

I ran the all new resize4fs as suggested by Stuart , and it made my day in
fact it made for the whole week's frustration :)

resize4fs /dev/vg0/logs
resize4fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg0/logs is mounted on /bin-logs; on-line resizing
required
old desc_blocks = 7, new_desc_blocks = 9
Performing an on-line resize of /dev/vg0/logs to 37408768 (4k) blocks.

The filesystem on /dev/vg0/logs is now 37408768 blocks long.


lvs
  LV   VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  data vg0  -wi-ao 350.00G
  logs vg0  -wi-ao *142.70G *


PS: I am raving fan of lvm all over again :)


thanks everyone and issue closed !


Tariq










On Fri, Aug 24, 2012 at 5:25 PM, Stuart D Gathman <stuart@bmsi.com> wrote:

>  On 08/23/2012 11:18 AM, tariq wali wrote:
>
>  lvresize to extend an lvm ? how
>
>  also I cant create a new lvm don't have that much space and the to
> extend the new one and it would mean downtime . don't think it's an issue
> with filesystem tools , lvm has NEVER been consistent in my case .
>
>   The resize2fs on RHEL5 does not support ext4.  Your error message is
> the one reported when you try to resize an ext4 filesystem with ext2/ext3
> tools.  You need to either install e4fsprogrs and use resize4fs (and
> e4fsck), or do the resize in the virtual machine you are apparently running
> a newer OS in.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>



-- 
*Tariq Wali.*

[-- Attachment #2: Type: text/html, Size: 6065 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[Zdenek Kabelac]

Dne 27.8.2012 13:46, tariq wali napsal(a):
> Guys , thanks much for your time on the issue, really appreciate it . I had
> tried everything suggested so far (lvresize/extend) updated filesystem
> tools etc
>
> @Stuart D Gathman , YOU ARE THE MAN SIR :) and nailed it down .
>
> I wanted to reproduce the same issue again and i did that not know how
> ignorant I was being ..
>
> # lvextend -L +40G /dev/vg0/bin-logs
>    Extending logical volume bin-logs to 110.00 GB
>    Logical volume bin-logs successfully resized
>
>
> lvs
>    LV       VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>    bin-logs vg0  -wi-ao *110.00G*
>    data     vg0  -wi-ao 380.00G
>
> resize2fs /dev/vg0/bin-logs
> resize2fs 1.39 (29-May-2006)
> resize2fs: Filesystem has unsupported feature(s) while trying to open
> /dev/vg0/bin-logs
> Couldn't find valid filesystem superblock.
>
> #this is where I would get psyched , i did the same thing to all my ext2/3
> filesystems and have extended file systems online without an issue for
> years ..but did I fforget the file system type this time , yes indeed I for
> got we have started doing ext4 on all our new servers and didn't realise
> ext4 fancies it's own bells and whistles ..
>
> I ran the all new resize4fs as suggested by Stuart , and it made my day in
> fact it made for the whole week's frustration :)
>
> resize4fs /dev/vg0/logs
> resize4fs 1.41.12 (17-May-2010)
> Filesystem at /dev/vg0/logs is mounted on /bin-logs; on-line resizing
> required
> old desc_blocks = 7, new_desc_blocks = 9
> Performing an on-line resize of /dev/vg0/logs to 37408768 (4k) blocks.
>
> The filesystem on /dev/vg0/logs is now 37408768 blocks long.
>
>
> lvs
>    LV   VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>    data vg0  -wi-ao 350.00G
>    logs vg0  -wi-ao *142.70G *
>
>
> PS: I am raving fan of lvm all over again :)
>
>
> thanks everyone and issue closed !
>

How about checking 'man lvresize'
and using option  '-r'  i.e.:

lvresize -r -L +40G /dev/vg0/bin-logs

That would be time-saver...

Zdenek

Re: [linux-lvm] lvextend NEVER works but screws up

[tariq wali]

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

thought I will update this thread , there is no e4fsprogs on  RHEL 6 for
ext4, and e2fsprogs ( e2fsck/resize2fs works just fine ) .

On Wed, Aug 29, 2012 at 2:00 PM, tariq wali <ganaiwali@gmail.com> wrote:

> not sure if -r with lvresize would pick ext4 filesystem also . but I will
> give it a try ..thanks
>
>
> On Tue, Aug 28, 2012 at 2:39 PM, Zdenek Kabelac <zkabelac@redhat.com>wrote:
>
>> Dne 27.8.2012 13:46, tariq wali napsal(a):
>>
>>> Guys , thanks much for your time on the issue, really appreciate it . I
>>> had
>>> tried everything suggested so far (lvresize/extend) updated filesystem
>>> tools etc
>>>
>>> @Stuart D Gathman , YOU ARE THE MAN SIR :) and nailed it down .
>>>
>>> I wanted to reproduce the same issue again and i did that not know how
>>> ignorant I was being ..
>>>
>>> # lvextend -L +40G /dev/vg0/bin-logs
>>>    Extending logical volume bin-logs to 110.00 GB
>>>    Logical volume bin-logs successfully resized
>>>
>>>
>>> lvs
>>>    LV       VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>>>    bin-logs vg0  -wi-ao *110.00G*
>>>
>>>    data     vg0  -wi-ao 380.00G
>>>
>>> resize2fs /dev/vg0/bin-logs
>>> resize2fs 1.39 (29-May-2006)
>>> resize2fs: Filesystem has unsupported feature(s) while trying to open
>>> /dev/vg0/bin-logs
>>> Couldn't find valid filesystem superblock.
>>>
>>> #this is where I would get psyched , i did the same thing to all my
>>> ext2/3
>>> filesystems and have extended file systems online without an issue for
>>> years ..but did I fforget the file system type this time , yes indeed I
>>> for
>>> got we have started doing ext4 on all our new servers and didn't realise
>>> ext4 fancies it's own bells and whistles ..
>>>
>>> I ran the all new resize4fs as suggested by Stuart , and it made my day
>>> in
>>> fact it made for the whole week's frustration :)
>>>
>>> resize4fs /dev/vg0/logs
>>> resize4fs 1.41.12 (17-May-2010)
>>> Filesystem at /dev/vg0/logs is mounted on /bin-logs; on-line resizing
>>> required
>>> old desc_blocks = 7, new_desc_blocks = 9
>>> Performing an on-line resize of /dev/vg0/logs to 37408768 (4k) blocks.
>>>
>>> The filesystem on /dev/vg0/logs is now 37408768 blocks long.
>>>
>>>
>>> lvs
>>>    LV   VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
>>>    data vg0  -wi-ao 350.00G
>>>    logs vg0  -wi-ao *142.70G *
>>>
>>>
>>>
>>> PS: I am raving fan of lvm all over again :)
>>>
>>>
>>> thanks everyone and issue closed !
>>>
>>>
>> How about checking 'man lvresize'
>> and using option  '-r'  i.e.:
>>
>> lvresize -r -L +40G /dev/vg0/bin-logs
>>
>> That would be time-saver...
>>
>> Zdenek
>>
>>
>
>
> --
> *Tariq Wali.*
>
>


-- 
*Tariq Wali.*

[-- Attachment #2: Type: text/html, Size: 3960 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[Stuart D Gathman]

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

Let me remind people that on RHEL5, running e2fsck on an ext4 filesystem 
will actually destroy data! Always
use fsck, which runs either e2fsck or e4fsck when e4fsprogs is 
installed.  On newer systems, where ext4 support is not tacked on as 
e4fsprogs, e2fsck handles both (but is it still a good habit to use fsck 
to run the proper checker).

On 10/04/2012 02:32 AM, tariq wali expounded in part:
>
>             resize2fs /dev/vg0/bin-logs
>             resize2fs 1.39 (29-May-2006)
>             resize2fs: Filesystem has unsupported feature(s) while
>             trying to open
>             /dev/vg0/bin-logs
>             Couldn't find valid filesystem superblock.
>
>             #this is where I would get psyched , i did the same thing
>             to all my ext2/3
>             filesystems and have extended file systems online without
>             an issue for
>             years ..but did I fforget the file system type this time ,
>             yes indeed I for
>             got we have started doing ext4 on all our new servers and
>             didn't realise
>             ext4 fancies it's own bells and whistles ..
>
>             I ran the all new resize4fs as suggested by Stuart , and
>             it made my day in
>             fact it made for the whole week's frustration :)
>
>             resize4fs /dev/vg0/logs
>             resize4fs 1.41.12 (17-May-2010)
>             Filesystem at /dev/vg0/logs is mounted on /bin-logs;
>             on-line resizing
>             required
>             old desc_blocks = 7, new_desc_blocks = 9
>             Performing an on-line resize of /dev/vg0/logs to 37408768
>             (4k) blocks.
>
>             The filesystem on /dev/vg0/logs is now 37408768 blocks long.
>


[-- Attachment #2: Type: text/html, Size: 3636 bytes --]

Re: [linux-lvm] lvextend NEVER works but screws up

[flavio-redhat]

On 08/23/2012 01:14 PM, tariq wali wrote:
> I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
> what I ran in order to extended
> 
> # lvextend -L +42.7G -n /dev/vg0/logs
>   Rounding up size to full physical extent 42.70 GB
>   Extending logical volume logs to 142.70 GB
>   Logical volume logs successfully resized
> 
> #resize2fs /dev/vg0/logs    ( and it gets screwed up here )
> resize2fs 1.39 (29-May-2006)
> *resize2fs: Filesystem has unsupported feature(s) while trying to open
> /dev/vg0/logs*
> *Couldn't find valid filesystem superblock.*

This problem seems to be with your filesystem tools, not with LVM. If I
were you I'd create a new LV, make a new filesystem, move all the files
on the new LV, mount it, remove the OLD LV and then extend the new LV.


-- 
Flavio Visentin

A computer is like an air conditioner,
it stops working when you open Windows

Re: [linux-lvm] lvextend NEVER works but screws up

[Brassow Jonathan]

On Aug 23, 2012, at 9:21 AM, flavio-redhat@zipman.it wrote:

> On 08/23/2012 01:14 PM, tariq wali wrote:
>> I wanted to use the free 42.7 G and allocate it to /bin-logs so this is
>> what I ran in order to extended
>> 
>> # lvextend -L +42.7G -n /dev/vg0/logs
>>  Rounding up size to full physical extent 42.70 GB
>>  Extending logical volume logs to 142.70 GB
>>  Logical volume logs successfully resized
>> 
>> #resize2fs /dev/vg0/logs    ( and it gets screwed up here )
>> resize2fs 1.39 (29-May-2006)
>> *resize2fs: Filesystem has unsupported feature(s) while trying to open
>> /dev/vg0/logs*
>> *Couldn't find valid filesystem superblock.*
> 
> This problem seems to be with your filesystem tools, not with LVM. If I
> were you I'd create a new LV, make a new filesystem, move all the files
> on the new LV, mount it, remove the OLD LV and then extend the new LV.

It does seem to be with the filesystem tools at first glance.  Presumably, the file system is still usable after you've resized the LV?  IOW, after 'lvextend' has resized the LV your (still small) file system should be usable.  If it is still usable at that point (try unmounting and mounting to ensure superblock is still in place), then you know the 'resize2fs' isn't working right.

 brassow

Re: [linux-lvm] lvextend NEVER works but screws up

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/23/2012 12:14 PM, tariq wali wrote:
> # lvextend -L +42.7G -n /dev/vg0/logs Rounding up size to full
> physical extent 42.70 GB Extending logical volume logs to 142.70
> GB Logical volume logs successfully resized

Afaik the -n is not necessary here - it's only meaningful with resize
operations if the --resizefs option is also given (so it only calls
fsadm resize and not fsadm check).

> #resize2fs /dev/vg0/logs    ( and it gets screwed up here ) 
> resize2fs 1.39 (29-May-2006) *resize2fs: Filesystem has unsupported
> feature(s) while trying to open /dev/vg0/logs* *Couldn't find valid
> filesystem superblock.*

This is the problem. You appear to be using a version of e2fsprogs
that is older than the version used to create the file system in the
first place. In this case they will give up and refuse to do anything
rather than potentially damage a file system that has unknown features
enabled.

> lvm version LVM version:     2.02.88(2)-RHEL5 (2012-01-20) Library
> version: 1.02.67-RHEL5 (2011-10-14) Driver version:  4.11.6

Can you post the version of e2fsprogs you have installed and also the
output of "dumpe2fs -h /dev/vg0/logs"?

Regards,
Bryn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA2W/8ACgkQ6YSQoMYUY95y8ACgwTykP1Z/izonns5vvM5dm8nf
/LMAn3zw8RYpabEJ38k5s9Lg5Xt7zlkr
=ipyA
-----END PGP SIGNATURE-----

Re: [linux-lvm] lvextend NEVER works but screws up

[Stuart D Gathman]

On Aug 23, Bryn M. Reeves transmitted in part:

>> #resize2fs /dev/vg0/logs    ( and it gets screwed up here )
>> resize2fs 1.39 (29-May-2006) *resize2fs: Filesystem has unsupported
>> feature(s) while trying to open /dev/vg0/logs* *Couldn't find valid
>> filesystem superblock.*
>
> This is the problem. You appear to be using a version of e2fsprogs
> that is older than the version used to create the file system in the
> first place. In this case they will give up and refuse to do anything
> rather than potentially damage a file system that has unknown features
> enabled.
>
>> lvm version LVM version:     2.02.88(2)-RHEL5 (2012-01-20) Library
>> version: 1.02.67-RHEL5 (2011-10-14) Driver version:  4.11.6
>
> Can you post the version of e2fsprogs you have installed and also the
> output of "dumpe2fs -h /dev/vg0/logs"?

I can guess pretty confidently what the problem is.  RHEL5 supports
ext2 and ext3, but *not* ext4 (unless you install ext4progs, and then
you have to run resize4fs, not resize2fs).  But it has a very stable
Xen.  The OP probably has a VM that uses ext4, and it trying to resize
the filesystem using the old resize2fs on his RHEL5 dom0.

What the OP *should* do:

1) after extending the LV, shutdown and startup the VM so that it sees
the new size, and run resize2fs in the VM (where it is the right
version and will do an online resize).

   or

2) install e4fsprogs in RHEL5, and use resize4fs on dom0