Extending a distributed LV

[Sundar_7]

I have a Volume group with two PVS. The VG has only one LV. The LV is distributed across the two PVS. Note the LVs are not mirrored.

LE PV1 PE1
00000 /dev/dsk/c14t5d4 00000
00001 /dev/dsk/c17t5d5 00000
00002 /dev/dsk/c14t5d4 00001
00003 /dev/dsk/c17t5d5 00001
00004 /dev/dsk/c14t5d4 00002
00005 /dev/dsk/c17t5d5 00002
00006 /dev/dsk/c14t5d4 00003
....................

I have a requirement to add 4 PVS to the VG. The PVs are going to be the same size as the current one in the VG.

Now the question is if I use lvextend command, will the new extends will be distributed across the new PVS or how the structure will be.

Appreciate any inputs.

Thanks,

Sundar

[Pete Randall]

Sundar,

I think this quote from the man page of lvextend answers your question:

"LVM always ensures that physical extent allocation
can satisfy the current allocation policy or policies."


Pete

[Jeff Schussele]

Hi Sundar,

I agree with Pete.
But it might ease your worries if you run lvdisplay against that LV & examine the output for Allocation to determine it is indeed distributed.

Rgds,
Jeff

[Jeff Schussele]

Hi (again) Sundara,

I re-read your post & believe you may also be asking what will happen to:

A) Existing extents - Nothing. They will not be redistibuted across all six PV. They will remain ditributed across the original two. You could backup the LV & recreate again using all six & then ALL PVs would be used to distibute from the get-go.

B) Newly created extents - They will be ditributed across all six extents in round-robin fashion UNTIL the original two PVs have exhausted their free extents. Then they will be ditributed evenly across the remaining four until they are exhausted.

I trust this helps.

Rgds,
Jeff

[Sundar_7]

Hi Jeff,

Exactly that is what I am looking for - what will happen to the existing and the new extends.

Do u folks see any potential bottlenecks in leaving the 2 disks as is, add the 4 new PVS and extend the LV rather than recreating it ?

I would guess this should not impact the performance... ??

Sundar.

[Todd McDaniel_1]

If you merely extend the VG with 4 new disks... you will have them available. Nothing will be done with them until you issue a command to add them to the LV... even then none of your current extent allocation will be moved to those new disks.

Your 4 new disks will simply be added to the LVol. They will be available but unallocated.. You will have to move data over to them if you so choose.

My guess is that you will have to backup your data to another fielsystem and then reassign the data to the Lvol after you add the 4 disks for a total of 6.

Then you can reallocate across all 6 disks.

[Todd McDaniel_1]

Oh sorry, I misread your post. You have a distributed LV. disregard my last post.

[Patrick Wallek]

Jeff hit the nail on the head with his post. However, when you extend the LV, your additional space will be spread across all 6 drives *ONLY* if you add the new drives to the PVG that the current 2 drives are a part of. You can do this by manually editing the /etc/lvmpvg file after you extend the VG, or as a part of the vgextend command with the '-g' option (I think -- check the man page to be sure).

As far as bottlenecks go, that depends entirely on your data. If you leave the data on the current 2 PVs, then whenever that data is requested it will only be read from those 2 disks, while all newer data that is written will be spread across 6 disks. The bottleneck issue will depend on how often your current data is accessed.

If I had the time to do it, I would seriously consider backing up your current data, blowing away the current LV, extending the VG with the new disks, create a new distributed LV with all of your disks, and then restore your data.

Why would I blow away the LV and re-create? Probably because I'm a glutten for punishment. ;) I just want to make sure that the LV will span all 6 disks when I restore the data. I doubt that there would be any problems just extending the LV, but since it was created originally with just 2 disks, you never know.