* [linux-lvm] cannot extend lv
@ 2003-01-18 4:36 Rainer.Lay
2003-01-18 10:57 ` idsfa
0 siblings, 1 reply; 6+ messages in thread
From: Rainer.Lay @ 2003-01-18 4:36 UTC (permalink / raw)
To: linux-lvm
I have a vg (data) with four drives /dev/sd[b-e]1
I created a 2 stripes lv (data1) with sd[bc]1
Now I want to add the remaining two drives to the lv, but lvextend
complains about missing pes! I tried also with a very small number of
pes - without success:
lvextend -l +400 /dev/data/data1 /dev/sde1 /dev/sdd1
lvextend -- extending logical volume "/dev/data/data1" to 35.45 GB
lvextend -- not enough free/allocatable physical extents to extend
logical volume "/dev/data/data1"
It returns error code 12:
12 error setting up VGDA for logical volume extension
which is not very useful in this case.
Any idea?
kind regards,
Rainer
here comes a vgdisplay:
vgdisplay -v
--- Volume group ---
VG Name data
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 1
Open LV 1
MAX LV Size 255.99 GB
Max PV 256
Cur PV 4
Act PV 4
VG Size 50.83 GB
PE Size 4 MB
Total PE 13012
Alloc PE / Size 8676 / 33.89 GB
Free PE / Size 4336 / 16.94 GB
VG UUID sIKhBA-LMrL-e0h0-5NEt-mVSZ-3SrM-2KB7XS
--- Logical volume ---
LV Name /dev/data/data1
VG Name data
LV Write Access read/write
LV Status available
LV # 1
# open 2
LV Size 33.89 GB
Current LE 8676
Allocated LE 8676
Stripes 2
Stripe size (KByte) 16
Allocation next free
Read ahead sectors 1024
Block device 58:0
--- Physical volumes ---
PV Name (#) /dev/sdb1 (3)
PV Status available / allocatable
Total PE / Free PE 4338 / 0
PV Name (#) /dev/sdc1 (2)
PV Status available / allocatable
Total PE / Free PE 4338 / 0
PV Name (#) /dev/sdd1 (1)
PV Status available / allocatable
Total PE / Free PE 2167 / 2167
PV Name (#) /dev/sde1 (4)
PV Status available / allocatable
Total PE / Free PE 2169 / 2169
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] cannot extend lv
2003-01-18 4:36 [linux-lvm] cannot extend lv Rainer.Lay
@ 2003-01-18 10:57 ` idsfa
0 siblings, 0 replies; 6+ messages in thread
From: idsfa @ 2003-01-18 10:57 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Sat, Jan 18, 2003 at 11:35:28AM +0000,
Rainer.Lay@informatik.uni-erlangen.de wrote:
> I have a vg (data) with four drives /dev/sd[b-e]1
> I created a 2 stripes lv (data1) with sd[bc]1
^^^^^^^
You cannot extend striped lvs onto new pvs. Even on the
same physical hardware. Once you have striped it, you are
tied to the pvs used.
If you think about it, this makes sense, as otherwise you
have some stripes containing more data than others. In fact,
as soon as the smallest pv is full, you will not be able to
extend the lv, even if there is room in the other pvs.
If you want to have the filesystem striped over all the disks, you
will need to create a new lv which is striped across them all,
transfer the data to it, delete the old lv and then extend the
new one.
Backups highly recommended.
Michael
--
Think Locally, Act Globally:
"It's cold in here ... I'd better release a few million tons of CFCs!"
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] cannot extend lv
@ 2003-01-19 3:15 Rainer.Lay
2003-01-19 12:07 ` idsfa
0 siblings, 1 reply; 6+ messages in thread
From: Rainer.Lay @ 2003-01-19 3:15 UTC (permalink / raw)
To: linux-lvm; +Cc: idsfa
My idea was not to make a 4 stripe set with 4 PV, but a 2 stripe set:
stripe1: aaaaaaaaabbbbbb
stripe2: cccccccccdddddd
so if PV a and c are full, PV b and d are used.
I would create a new lv as you suggested, but drives a and c are two
times bigger than b and d, so I thought about the above solution.
Rainer
>> I have a vg (data) with four drives /dev/sd[b-e]1
>> I created a 2 stripes lv (data1) with sd[bc]1
> ^^^^^^^
>
> You cannot extend striped lvs onto new pvs. Even on the
> same physical hardware. Once you have striped it, you are
> tied to the pvs used.
>
> If you think about it, this makes sense, as otherwise you
> have some stripes containing more data than others. In fact,
> as soon as the smallest pv is full, you will not be able to
> extend the lv, even if there is room in the other pvs.
>
> If you want to have the filesystem striped over all the disks, you
> will need to create a new lv which is striped across them all,
> transfer the data to it, delete the old lv and then extend the
> new one.
>
> Backups highly recommended.
>
> Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] cannot extend lv
2003-01-19 3:15 Rainer.Lay
@ 2003-01-19 12:07 ` idsfa
2003-01-19 13:31 ` Alasdair G Kergon
2003-01-19 15:00 ` Steven Lembark
0 siblings, 2 replies; 6+ messages in thread
From: idsfa @ 2003-01-19 12:07 UTC (permalink / raw)
To: linux-lvm; +Cc: Rainer.Lay
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
On Sun, Jan 19, 2003 at 10:16:04AM +0000,
Rainer.Lay@informatik.uni-erlangen.de wrote:
> My idea was not to make a 4 stripe set with 4 PV, but a 2 stripe set:
>
> stripe1: aaaaaaaaabbbbbb
> stripe2: cccccccccdddddd
>
> so if PV a and c are full, PV b and d are used.
Striping doesn't work that way. It stripes across all pvs EVENLY
to improve access speeds (the whole reason to stripe). The only
way to do what you want would have been to use kernel RAID to combine
the physical devices into a single logical device before creating the
stripe set.
> I would create a new lv as you suggested, but drives a and c are two
> times bigger than b and d, so I thought about the above solution.
I understand, I went through the same exercise two months ago. I
borrowed a disk from a friend, moved all of the data to it, and rebuilt
my whole VG setup. It was a major pain in the neck.
Michael
--
Think Locally, Act Globally:
"It's cold in here ... I'd better release a few million tons of CFCs!"
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] cannot extend lv
2003-01-19 12:07 ` idsfa
@ 2003-01-19 13:31 ` Alasdair G Kergon
2003-01-19 15:00 ` Steven Lembark
1 sibling, 0 replies; 6+ messages in thread
From: Alasdair G Kergon @ 2003-01-19 13:31 UTC (permalink / raw)
To: linux-lvm
On Sun, Jan 19, 2003 at 12:07:53PM -0600, idsfa@visi.com wrote:
> The only
> way to do what you want would have been to use kernel RAID to combine
> the physical devices into a single logical device before creating the
> stripe set.
Or try out LVM2 which no longer imposes these restrictions when
extending striped volumes. (You can vary the number of stripes and the
stripesize.)
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] cannot extend lv
2003-01-19 12:07 ` idsfa
2003-01-19 13:31 ` Alasdair G Kergon
@ 2003-01-19 15:00 ` Steven Lembark
1 sibling, 0 replies; 6+ messages in thread
From: Steven Lembark @ 2003-01-19 15:00 UTC (permalink / raw)
To: linux-lvm
> I understand, I went through the same exercise two months ago. I
> borrowed a disk from a friend, moved all of the data to it, and rebuilt
> my whole VG setup. It was a major pain in the neck.
But it's the only way. This is not unique to Sistina's
implementation. Once the filesystem has been striped at
a low level (vs. lvextending it to alternate disks at
the extent level) there isn't any good way to move the
sripes around.
I'd suggest picking up a backup device, though, instead
of a diskdrive. The last thing you need is for a borrowed
drive to croak while you're re-arranging the PV's.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 773 252 1080
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-19 15:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-18 4:36 [linux-lvm] cannot extend lv Rainer.Lay
2003-01-18 10:57 ` idsfa
-- strict thread matches above, loose matches on Subject: below --
2003-01-19 3:15 Rainer.Lay
2003-01-19 12:07 ` idsfa
2003-01-19 13:31 ` Alasdair G Kergon
2003-01-19 15:00 ` Steven Lembark
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.