* [linux-lvm] lvcreate fails
@ 2012-01-09 21:08 Marcus Haarmann
2012-01-10 16:36 ` Peter M. Petrakis
0 siblings, 1 reply; 4+ messages in thread
From: Marcus Haarmann @ 2012-01-09 21:08 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]
Hi experts,
I have configured an external disk array on Ubuntu (amd64, 2.6.32
kernel) with lvm2 (2.02.54)
The setup is as follows:
--- Physical volume ---
PV Name /dev/fc_keep1a_1 (this is a symbolic link to a
fibre channel device)
VG Name vg_uni
PV Size 555,23 GiB / not usable 2,20 MiB
Allocatable NO
PE Size 4,00 MiB
Total PE 142139
Free PE 65339
Allocated PE 76800
PV UUID SmOTSP-wPEd-ZruJ-XP8n-WpoL-anDN-ccG7dM
vgdisplay vg_uni
--- Volume group ---
VG Name vg_uni
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 20
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 555,23 GiB
PE Size 4,00 MiB
Total PE 142139
Alloc PE / Size 76800 / 300,00 GiB
Free PE / Size 65339 / 255,23 GiB
VG UUID 0VNl5W-W22T-HEow-LvNx-gopm-nS0z-FpjZvi
This is for a database working with raw devices (without filesystem), I
allocated multiple partitions:
100 GB root
50 GB blob1
50 GB blob2
100 GB data1
When I try to allocate another area with 10 GB for a temporary space, I
get an error:
lvcreate -L 10G -n dbs_uni_tmp vg_uni
Insufficient free space: 2560 extents needed, but only 0 available
I did -vvv so the layout is printed (note there have been other lvm
partitions which have been dropped):
Using cached label for /dev/fc_keep1a_1
Using cached label for /dev/fc_keep1a_1
Read vg_unister metadata (20) from /dev/fc_keep1a_1 at 47104
size 1723
/dev/fc_keep1a_1 0: 0 25600: dbs_uni_root(0:0)
/dev/fc_keep1a_1 1: 25600 25600: dbs_uni_data1(0:0)
/dev/fc_keep1a_1 2: 51200 64000: NULL(0:0)
/dev/fc_keep1a_1 3: 115200 12800: dbs_uni_blob1(0:0)
/dev/fc_keep1a_1 4: 128000 12800: dbs_uni_blob2(0:0)
/dev/fc_keep1a_1 5: 140800 1339: NULL(0:0)
Archiving volume group "vg_unister" metadata (seqno 20).
Creating logical volume dbs_unister_tmp
Insufficient free space: 1338 extents needed, but only 0 available
Unlocking /var/lock/lvm/V_vg_unister
_undo_flock /var/lock/lvm/V_vg_unister
Closed /dev/fc_keep1a_1
What can I do to be able to use the space ?
Thank you all for your thoughts !
Marcus Haarmann
[-- Attachment #2: Type: text/html, Size: 7511 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [linux-lvm] lvcreate fails 2012-01-09 21:08 [linux-lvm] lvcreate fails Marcus Haarmann @ 2012-01-10 16:36 ` Peter M. Petrakis 2012-01-17 8:50 ` Marcus Haarmann 0 siblings, 1 reply; 4+ messages in thread From: Peter M. Petrakis @ 2012-01-10 16:36 UTC (permalink / raw) To: linux-lvm Hi, On 01/09/2012 04:08 PM, Marcus Haarmann wrote: > Hi experts, > > I have configured an external disk array on Ubuntu (amd64, 2.6.32 kernel) with lvm2 (2.02.54) > The setup is as follows: > > --- Physical volume --- > PV Name /dev/fc_keep1a_1 (this is a symbolic link to a fibre channel device) > VG Name vg_uni > PV Size 555,23 GiB / not usable 2,20 MiB > Allocatable NO > PE Size 4,00 MiB > Total PE 142139 > Free PE 65339 > Allocated PE 76800 > PV UUID SmOTSP-wPEd-ZruJ-XP8n-WpoL-anDN-ccG7dM > > vgdisplay vg_uni > --- Volume group --- > VG Name vg_uni > System ID > Format lvm2 > Metadata Areas 1 > Metadata Sequence No 20 > VG Access read/write > VG Status resizable > MAX LV 0 > Cur LV 4 > Open LV 0 > Max PV 0 > Cur PV 1 > Act PV 1 > VG Size 555,23 GiB > PE Size 4,00 MiB > Total PE 142139 > Alloc PE / Size 76800 / 300,00 GiB > Free PE / Size 65339 / 255,23 GiB > VG UUID 0VNl5W-W22T-HEow-LvNx-gopm-nS0z-FpjZvi > This is for a database working with raw devices (without filesystem), I allocated multiple partitions: > 100 GB root > 50 GB blob1 > 50 GB blob2 > 100 GB data1 > > When I try to allocate another area with 10 GB for a temporary space, I get an error: > lvcreate -L 10G -n dbs_uni_tmp vg_uni > Insufficient free space: 2560 extents needed, but only 0 available > > I did -vvv so the layout is printed (note there have been other lvm partitions which have been dropped): > Using cached label for /dev/fc_keep1a_1 > Using cached label for /dev/fc_keep1a_1 > Read vg_unister metadata (20) from /dev/fc_keep1a_1 at 47104 size 1723 > /dev/fc_keep1a_1 0: 0 25600: dbs_uni_root(0:0) > /dev/fc_keep1a_1 1: 25600 25600: dbs_uni_data1(0:0) > /dev/fc_keep1a_1 2: 51200 64000: NULL(0:0) > /dev/fc_keep1a_1 3: 115200 12800: dbs_uni_blob1(0:0) > /dev/fc_keep1a_1 4: 128000 12800: dbs_uni_blob2(0:0) > /dev/fc_keep1a_1 5: 140800 1339: NULL(0:0) > Archiving volume group "vg_unister" metadata (seqno 20). > Creating logical volume dbs_unister_tmp > Insufficient free space: 1338 extents needed, but only 0 available > Unlocking /var/lock/lvm/V_vg_unister > _undo_flock /var/lock/lvm/V_vg_unister > Closed /dev/fc_keep1a_1 > What can I do to be able to use the space ? Did you notice that the backing store was state where Allocatable is NO? Try, # pvchange -x y /dev/fc_keep1a_1 I question the use of that symlink, is it being maintained by UDEV or multipath friendly names? Could you please elaborate more concerning the events leading to this point? It doesn't make much sense that LVM would flip the Allocatable bit without some good external reason. Thanks. Peter > Thank you all for your thoughts ! > > Marcus Haarmann > > > > _______________________________________________ > 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] lvcreate fails 2012-01-10 16:36 ` Peter M. Petrakis @ 2012-01-17 8:50 ` Marcus Haarmann 2012-01-17 18:34 ` Peter M. Petrakis 0 siblings, 1 reply; 4+ messages in thread From: Marcus Haarmann @ 2012-01-17 8:50 UTC (permalink / raw) To: linux-lvm Hi, thanks for the input, found the (same) resolution after hours of reading and trying... (I am newly subscribed to the list, so the response reached me on the following day). But yes, the link is maintained by udev. I have no idea why especially this device was in a mode that allocation was prevented. We surely did not issue a pvchange command to do this. (other devices also maintained by lvm, in the same SAN, were allocatable. Maybe it is because the array is visible to more than one machine at the same time due to the fibre switch. We can address the LVM from more than one machine, which is by intention to be able to fail over. Thank you for your ideas. Best regards, Marcus -----Original Message----- From: Peter M. Petrakis [mailto:peter.petrakis@canonical.com] Sent: Tuesday, January 10, 2012 5:37 PM To: linux-lvm@redhat.com Subject: Re: [linux-lvm] lvcreate fails Hi, On 01/09/2012 04:08 PM, Marcus Haarmann wrote: > Hi experts, > > I have configured an external disk array on Ubuntu (amd64, 2.6.32 > kernel) with lvm2 (2.02.54) The setup is as follows: > > --- Physical volume --- > PV Name /dev/fc_keep1a_1 (this is a symbolic link to a fibre channel device) > VG Name vg_uni > PV Size 555,23 GiB / not usable 2,20 MiB > Allocatable NO > PE Size 4,00 MiB > Total PE 142139 > Free PE 65339 > Allocated PE 76800 > PV UUID SmOTSP-wPEd-ZruJ-XP8n-WpoL-anDN-ccG7dM > > vgdisplay vg_uni > --- Volume group --- > VG Name vg_uni > System ID > Format lvm2 > Metadata Areas 1 > Metadata Sequence No 20 > VG Access read/write > VG Status resizable > MAX LV 0 > Cur LV 4 > Open LV 0 > Max PV 0 > Cur PV 1 > Act PV 1 > VG Size 555,23 GiB > PE Size 4,00 MiB > Total PE 142139 > Alloc PE / Size 76800 / 300,00 GiB > Free PE / Size 65339 / 255,23 GiB > VG UUID 0VNl5W-W22T-HEow-LvNx-gopm-nS0z-FpjZvi > This is for a database working with raw devices (without filesystem), I allocated multiple partitions: > 100 GB root > 50 GB blob1 > 50 GB blob2 > 100 GB data1 > > When I try to allocate another area with 10 GB for a temporary space, I get an error: > lvcreate -L 10G -n dbs_uni_tmp vg_uni > Insufficient free space: 2560 extents needed, but only 0 available > > I did -vvv so the layout is printed (note there have been other lvm partitions which have been dropped): > Using cached label for /dev/fc_keep1a_1 > Using cached label for /dev/fc_keep1a_1 > Read vg_unister metadata (20) from /dev/fc_keep1a_1 at 47104 size 1723 > /dev/fc_keep1a_1 0: 0 25600: dbs_uni_root(0:0) > /dev/fc_keep1a_1 1: 25600 25600: dbs_uni_data1(0:0) > /dev/fc_keep1a_1 2: 51200 64000: NULL(0:0) > /dev/fc_keep1a_1 3: 115200 12800: dbs_uni_blob1(0:0) > /dev/fc_keep1a_1 4: 128000 12800: dbs_uni_blob2(0:0) > /dev/fc_keep1a_1 5: 140800 1339: NULL(0:0) > Archiving volume group "vg_unister" metadata (seqno 20). > Creating logical volume dbs_unister_tmp > Insufficient free space: 1338 extents needed, but only 0 available > Unlocking /var/lock/lvm/V_vg_unister > _undo_flock /var/lock/lvm/V_vg_unister > Closed /dev/fc_keep1a_1 > What can I do to be able to use the space ? Did you notice that the backing store was state where Allocatable is NO? Try, # pvchange -x y /dev/fc_keep1a_1 I question the use of that symlink, is it being maintained by UDEV or multipath friendly names? Could you please elaborate more concerning the events leading to this point? It doesn't make much sense that LVM would flip the Allocatable bit without some good external reason. Thanks. Peter > Thank you all for your thoughts ! > > Marcus Haarmann > > > > _______________________________________________ > 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/ _______________________________________________ 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] lvcreate fails 2012-01-17 8:50 ` Marcus Haarmann @ 2012-01-17 18:34 ` Peter M. Petrakis 0 siblings, 0 replies; 4+ messages in thread From: Peter M. Petrakis @ 2012-01-17 18:34 UTC (permalink / raw) To: linux-lvm On 01/17/2012 03:50 AM, Marcus Haarmann wrote: > Hi, > > thanks for the input, found the (same) resolution after hours of reading > and trying... > (I am newly subscribed to the list, so the response reached me on the > following day). > But yes, the link is maintained by udev. > I have no idea why especially this device was in a mode that allocation > was prevented. We surely did not issue a > pvchange command to do this. (other devices also maintained by lvm, in > the same SAN, were allocatable. > Maybe it is because the array is visible to more than one machine at the > same time due to the fibre switch. That would do it, your LUN is incorrectly zoned, LVM will never work right. Whoever touched it last will trespass and take ownership of the LUN. What you need is a proper zone(s) configuration and use multipath. That's way beyond the scope of this list. You'll need to invest in the solution yourself. A proper SAN topology would be a good start, there are many texts and internet resources on the subject. There are plenty of resources on Linux Multipath, it's not really distro specific sans installation and other platform dependent stuff. > We can address the LVM from more than one machine, which is by intention > to be able to fail over. You need to use clustered LVM [1] for that, and depending on your use cases, a clustered file system [2] as well. Peter 1. http://sourceware.org/cluster/clvm/ 2. http://sourceware.org/cluster/gfs/ http://oss.oracle.com/projects/ocfs2/ > Thank you for your ideas. > > Best regards, > > Marcus > > -----Original Message----- > From: Peter M. Petrakis [mailto:peter.petrakis@canonical.com] > Sent: Tuesday, January 10, 2012 5:37 PM > To: linux-lvm@redhat.com > Subject: Re: [linux-lvm] lvcreate fails > > Hi, > > On 01/09/2012 04:08 PM, Marcus Haarmann wrote: >> Hi experts, >> >> I have configured an external disk array on Ubuntu (amd64, 2.6.32 >> kernel) with lvm2 (2.02.54) The setup is as follows: >> >> --- Physical volume --- >> PV Name /dev/fc_keep1a_1 (this is a symbolic link to a > fibre channel device) >> VG Name vg_uni >> PV Size 555,23 GiB / not usable 2,20 MiB >> Allocatable NO >> PE Size 4,00 MiB >> Total PE 142139 >> Free PE 65339 >> Allocated PE 76800 >> PV UUID SmOTSP-wPEd-ZruJ-XP8n-WpoL-anDN-ccG7dM >> >> vgdisplay vg_uni >> --- Volume group --- >> VG Name vg_uni >> System ID >> Format lvm2 >> Metadata Areas 1 >> Metadata Sequence No 20 >> VG Access read/write >> VG Status resizable >> MAX LV 0 >> Cur LV 4 >> Open LV 0 >> Max PV 0 >> Cur PV 1 >> Act PV 1 >> VG Size 555,23 GiB >> PE Size 4,00 MiB >> Total PE 142139 >> Alloc PE / Size 76800 / 300,00 GiB >> Free PE / Size 65339 / 255,23 GiB >> VG UUID 0VNl5W-W22T-HEow-LvNx-gopm-nS0z-FpjZvi >> This is for a database working with raw devices (without filesystem), > I allocated multiple partitions: >> 100 GB root >> 50 GB blob1 >> 50 GB blob2 >> 100 GB data1 >> >> When I try to allocate another area with 10 GB for a temporary space, > I get an error: >> lvcreate -L 10G -n dbs_uni_tmp vg_uni >> Insufficient free space: 2560 extents needed, but only 0 available >> >> I did -vvv so the layout is printed (note there have been other lvm > partitions which have been dropped): >> Using cached label for /dev/fc_keep1a_1 >> Using cached label for /dev/fc_keep1a_1 >> Read vg_unister metadata (20) from /dev/fc_keep1a_1 at 47104 > size 1723 >> /dev/fc_keep1a_1 0: 0 25600: dbs_uni_root(0:0) >> /dev/fc_keep1a_1 1: 25600 25600: dbs_uni_data1(0:0) >> /dev/fc_keep1a_1 2: 51200 64000: NULL(0:0) >> /dev/fc_keep1a_1 3: 115200 12800: dbs_uni_blob1(0:0) >> /dev/fc_keep1a_1 4: 128000 12800: dbs_uni_blob2(0:0) >> /dev/fc_keep1a_1 5: 140800 1339: NULL(0:0) >> Archiving volume group "vg_unister" metadata (seqno 20). >> Creating logical volume dbs_unister_tmp >> Insufficient free space: 1338 extents needed, but only 0 available >> Unlocking /var/lock/lvm/V_vg_unister >> _undo_flock /var/lock/lvm/V_vg_unister >> Closed /dev/fc_keep1a_1 >> What can I do to be able to use the space ? > > Did you notice that the backing store was state where Allocatable is NO? > > Try, # pvchange -x y /dev/fc_keep1a_1 > > I question the use of that symlink, is it being maintained by UDEV or > multipath friendly names? Could you please elaborate more concerning the > events leading to this point? It doesn't make much sense that LVM would > flip the Allocatable bit without some good external reason. Thanks. > > Peter > >> Thank you all for your thoughts ! >> >> Marcus Haarmann >> >> >> >> _______________________________________________ >> 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/ > > _______________________________________________ > 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/ > > > > _______________________________________________ > 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-17 18:34 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-09 21:08 [linux-lvm] lvcreate fails Marcus Haarmann 2012-01-10 16:36 ` Peter M. Petrakis 2012-01-17 8:50 ` Marcus Haarmann 2012-01-17 18:34 ` Peter M. Petrakis
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).