* [linux-lvm] vgextend path to device should'n be allowed
@ 2009-12-20 14:01 Maurizio Marini Gmail
2009-12-20 18:43 ` Milan Broz
0 siblings, 1 reply; 2+ messages in thread
From: Maurizio Marini Gmail @ 2009-12-20 14:01 UTC (permalink / raw)
To: linux-lvm; +Cc: maumar
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [linux-lvm] vgextend path to device should'n be allowed
2009-12-20 14:01 [linux-lvm] vgextend path to device should'n be allowed Maurizio Marini Gmail
@ 2009-12-20 18:43 ` Milan Broz
0 siblings, 0 replies; 2+ messages in thread
From: Milan Broz @ 2009-12-20 18:43 UTC (permalink / raw)
To: LVM general discussion and development; +Cc: Maurizio Marini Gmail, maumar
On 12/20/2009 03:01 PM, Maurizio Marini Gmail wrote:
> IMHO, vgextend should check input and deny operation on a device instead of a
> volume group name; it should abort with an error,
...
> After extending whic /dev/sdc of 80G using wrong statement:
> vgextend /dev/mapper/VolGroup01 /dev/sdc
this works correctly with recent version of lvm2 (despite the strange syntax).
Please can you try to upgrade lvm2 (to RHEL/CentOS 5.4 version, the reported
version is from 5.3) and try it again (bu after restoring correct metadata)?
> Now, to fix it, can I issue:
> vgreduce --force --removemissing VolGroup01
The best is revert metadata to version before the failed operation
(you pasted the correct version above:-) using vgcfgrestore command.
(The whole problem is stored "MISSING" flag in metadata, you can
also use last metadata backup, remove that flag manually and restore this
edited version.)
Milan
--
mbroz@redhat.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-12-20 18:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-20 14:01 [linux-lvm] vgextend path to device should'n be allowed Maurizio Marini Gmail
2009-12-20 18:43 ` Milan Broz
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).