Re: [linux-lvm] lvcreate fails

["Peter M. Petrakis" <peter.petrakis@canonical.com>]

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/