Cannot lvextend - not enough free extents - again!

[Patrick Wallek]

When you try to extend this LV, it will try to evenly extend it over the # of PVs specified in the 'stripes' parameter, which in this case is 47.

You are NOT going to be able to extend this VG without adding 47 more PVs. Just adding 10 PVs is NOT going to work.

[RajuD]

Hi ConnieK ,

It is impossible to extend the lv unless you allocated 47luns.

Possible solution...
Take complete filesystem backup of LV persent in the vg.

Destroy all the luns

Recreate the vg

Restore the backp.

[shanmuhanandam]

Hi,
As per the output you given, your existing lv is striped accross 47 luns. for extending the same lv you need more 47 luns.
Or else take the entire lv backup, remove it, then add 10 new luns, create the new lv, then restore the data.

Thanks,
Shan,.

[ConnieK]

Now I understand! I appreciate all the input and the clarifications at the bottom.

I did not build the original vg or lv, so I had no idea what was done. And still have no idea WHY it was done this way - striping over 47 luns!

I intend to clarify/verify with the customer that this is exactly what is wanted meaning actual striping of data over 57 LUNs (about 1824 GB) - to back up the data for restore, to destroy the existing lv, add in the additional 10 LUNs, and recreate the lv, striping across 57 LUNs, and then restore the data.

Also, I will need to check to ensure I actually can create one lv that big (1,867,776 MB).

[RajuD]

HI ConnieK,

sorry for the late reply...

I hope it could be a complex task to take complete data backup; since the data present in the volume group is huge in size.

I belive this vg has been created purely to improve performace, the lv presented in the volume might provide you output of read performance for the user...

Suggestion: Kindly co-ordinate with your application team / Customer get the exact requirement; Check with them if they able to utilize a new volume group by allocating 10 if you create...

[chris huys_4]

Hi,

You seem to have figured it out, but for future reference. ;)

When in doubt, design it out, so in my best ascii-art ;)

This is the current situation.

column1 column2 column47
lun 1 lun 2 ... lun 47
c18t7d2 c18t7d3 c18t13d0
+------+ +-----+ +------+
LE0|PE0 |LE1 |PE0 | ... LE46|PE0 |
+------+ +-----+ +------+
LE47|PE1 |LE49 |PE1 | ... LE93|PE1 |
+------+ +-----+ +------+
. . .
. . .
. . .
LE |PE268 |LE |PE268| ...LE |PE268 |
12596| |12596| | 12642| |
+------+ +-----+ +------+

The "first" stripe exists out of logical extent 0, LE0, till, logical extent 46, LE46, i.e.
all "physical extent 0", PE0, of all 47 luns.

NOTE: "stripes are the rows, luns the columns".

The "second" stripe exists out of LE47 till LE93, i.e. all "physical extents 1"
of all 47 luns.

The "269th" stripe, exists out of LE12596 till LE12642, i.e. all PE268 of all 47 luns.

NOTE: We "say its a 47 stripes logical volume", but what we "mean" with that,
in fact, is that 1 stripe, consists out of 47 luns, not that the volume
contains 47 stripes, as you can see in the above volume, which has a total of 269 stripes.

Every lun until now had 269 physical extents, PE0 till PE269, and each
extent is 128Mbyte in size, PE Size (Mbytes) 128.

Thus every of the 47 existing luns, until now, was 128Mbyte*269PE=34432 Mbyte
in size, or around 33Gbyte in size.

Now by adding 10 extra luns of around 33 Gbyte, what was done in fact, ..

column1 column2 column47
lun 1 lun 2 ... lun 47
c18t7d2 c18t7d3 c18t13d0
+-------+ +------+ +------+
LE0|PE0 |LE1 |PE0 | ... LE46|PE0 |
+-------+ +------+ +------+
LE47|PE1 |LE48 |PE1 | ... LE93|PE1 |
+-------+ +------+ +------+
. . .
. . .
. . .
LE |PE268 |LE |PE268 | ...LE |PE268 |
12596| |12596| | . 12642| |
+-------+ +------+ . +------+
|lun48 | |lun49 | . |lun57 |.
|c16t2d0| |cxtydz| |cx9ty9dz9|
+-------+ +------+ +--------+
LE |PE269 |LE |PE269 |.LE |PE269 |
12643| |12644| |.12652| |
+-------+ +------+ +-------+
LE |PE270 | |PE270 | |PE270 |
12653| | | | | |

.. was that while, "column1", "is extended", with lun48, the first of the 10 newly added luns,
and this up to "column10", which is extended with lun57, the 10th of the 10 newly added luns,
after this "the columns11 till columns 47" "couldnt extent" with a "newly added lun" anymore..
And thus no new stripes of 47 luns could be created anymore and thus the lvextend failed.

Destroying the logical volume and creating a 57 striped logical volume and then restoring the
data will work, but will also make that in the future, when the logical volume would need again
to be extended, the same problem will exist, now not with 47 luns, but instead with 57 luns.


Personally, I would just destroy the logical volume and just create a 'normal', i.e. not striped,
logical volume of now 57 luns and restore the data to such a logical volume, or at least go to
a 8 striped volume or some such.

Yes, you might loose some performance, but todays diskarrays cache/logic, should alleviate most
of it, and extending the logical volume in the future, will not get you into the same kind of problems.

NOTE: LVM is just not flexible enough to consider striping, especially large amount of luns per stripe,
(payable) VxVM is must better for this purpose as its allows for online changing of the number of stripes.

Greetz,
Chris

[ConnieK]

Closed