linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Maurizio Marini Gmail <marini.maurizio@gmail.com>
To: linux-lvm@redhat.com
Cc: maumar@datalogica.com
Subject: [linux-lvm] vgextend path to device should'n be allowed
Date: Sun, 20 Dec 2009 15:01:31 +0100	[thread overview]
Message-ID: <784f9de10912200601o69fbbf58r155eccd0f11eb287@mail.gmail.com> (raw)

IMHO, vgextend should check input and deny operation on a device instead of a
volume group name; it should abort with an error,
I dunno if this is a bug or an RFE.

For example, my case:
I hed this VolGroup01 before extending:

cat VolGroup01_00002.vg
# Generated by LVM2 version 2.02.40-RHEL5 (2008-10-24): Sat Dec 19 23:08:48 2009

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'vgextend
/dev/mapper/VolGroup01 /dev/sdc'"

creation_host = "backup_xyz.xzy.tld"        # Linux backup_xyz.xzy.tld
2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686
creation_time = 1261260528      # Sat Dec 19 23:08:48 2009

VolGroup01 {
        id = "3UUn79-YUF7-MULJ-yvCf-axBU-8gtU-vAd9X7"
        seqno = 2
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192              # 4 Megabytes
        max_lv = 0
        max_pv = 0

        physical_volumes {

                pv0 {
                        id = "qf0ApW-42u1-nlyq-2TTn-MIgB-3dT1-BNe3GF"
                        device = "/dev/sdb"     # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 524288000    # 250 Gigabytes
                        pe_start = 384
                        pe_count = 63999        # 249,996 Gigabytes
                }
        }

        logical_volumes {

                lvol0 {
                        id = "A507we-8Kda-srlT-1MjO-lR7F-k0Xo-powd5x"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 63999    # 249,996 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                }
        }
}


there was uno log. volume of 260G.

After extending whic /dev/sdc of 80G using wrong statement:
vgextend /dev/mapper/VolGroup01 /dev/sdc

I got:
 cat VolGroup01_00003.vg
# Generated by LVM2 version 2.02.40-RHEL5 (2008-10-24): Sat Dec 19 23:09:19 2009

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'lvextend -l 100%VG
/dev/mapper/VolGroup01-lvol0'"

creation_host = "backup_xxx.yyy.zzz"        # Linux backup_xxx.yyy.zzz
2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686
creation_time = 1261260559      # Sat Dec 19 23:09:19 2009

VolGroup01 {
        id = "3UUn79-YUF7-MULJ-yvCf-axBU-8gtU-vAd9X7"
        seqno = 3
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192              # 4 Megabytes
        max_lv = 0
        max_pv = 0

        physical_volumes {

                pv0 {
                        id = "qf0ApW-42u1-nlyq-2TTn-MIgB-3dT1-BNe3GF"
                        device = "unknown device"       # Hint only

                        status = ["ALLOCATABLE"]
                        flags = ["MISSING"]
                        dev_size = 524288000    # 250 Gigabytes
                        pe_start = 384
                        pe_count = 63999        # 249,996 Gigabytes
                }

                pv1 {
                        id = "6LNqzy-8BzO-9NBP-iF3a-b0a0-5LXP-NSqy0B"
                        device = "/dev/sdc"     # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 167772160    # 80 Gigabytes
                        pe_start = 384
                        pe_count = 20479        # 79,9961 Gigabytes
                }
        }

        logical_volumes {

                lvol0 {
                        id = "A507we-8Kda-srlT-1MjO-lR7F-k0Xo-powd5x"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 63999    # 249,996 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                }
        }
}


As you can see, the change was completed but /dev/sdb has lost his
UUID; so you cannot say:
[23:08:27 root@backup_xxx ~ ]# vgextend /dev/mapper/VolGroup01 /dev/sdc
  Volume group "VolGroup01" successfully extended

this *successfully* is not such, at all :(

You should check against errors in input data, else "garbage in, garbage out".

Now, to fix it, can I issue:
vgreduce --force  --removemissing VolGroup01

like suggested here:

 vgreduce -t --removemissing VolGroup01
  Test mode: Metadata will NOT be updated.
  Couldn't find device with uuid
'qf0ApW-42u1-nlyq-2TTn-MIgB-3dT1-BNe3GF'.
  Couldn't find device with uuid
'qf0ApW-42u1-nlyq-2TTn-MIgB-3dT1-BNe3GF'.
  WARNING: Partial LV lvol0 needs to be repaired or removed.
  WARNING: There are still partial LVs in VG VolGroup01.
  To remove them unconditionally use: vgreduce --removemissing
--force.
  Proceeding to remove empty missing PVs.

I would remove /dev/sdb from VolGroup01, then
vgremove VolGroup01

then:
pvcreate /dev/sdb

then:
vgcreate VolGroup01 /dev/sdb


Hopefully, i will have again what i had before wrong extend.

Do u think this is the right way to do it?

Tia

Maurizio

             reply	other threads:[~2009-12-20 14:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-20 14:01 Maurizio Marini Gmail [this message]
2009-12-20 18:43 ` [linux-lvm] vgextend path to device should'n be allowed Milan Broz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=784f9de10912200601o69fbbf58r155eccd0f11eb287@mail.gmail.com \
    --to=marini.maurizio@gmail.com \
    --cc=linux-lvm@redhat.com \
    --cc=maumar@datalogica.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).