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