[linux-lvm] vgextend path to device should'n be allowed
Maurizio Marini Gmail
marini.maurizio at gmail.com
Sun Dec 20 14:01:31 UTC 2009
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 at 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
More information about the linux-lvm
mailing list