Add physical extents to physical volume

[Alex Lavrov.]

Hello,
is it possible? Or the only way to do it it's to drop the physical volume and recreate it?

thanx.

[Pete Randall · Accepted solution]

Well, it's a physical limitation sort of thing - the physical volume can only have so many physical extents and you can't increase that. However, you could add another physical volume to your Volume Group with vgextend - this would increase the number of physical extents available.


Pete

[RAC_1]

What exactly you want?? Extend the lvol?? there is no way to add extends to a PV-per say.

Anil

[Alex Lavrov.]

Yep, but we kinda didn't want too many physical volumes in one VG ....


Thanx!

[Bill Hassell]

The concept of a volume group is to remove the concept of physical disks from storage requirements. So having 50 disks in a volume group is just fine--EXCEPT you must do this when the VG is first created, or use vgcreate with -e and -s options large enough to cover the total number of extents that will be needed. Once you create a VG, all the extents that can ever be used are fixed. So if you have a VG with one disk and you want to vgextend it with 5 more disks, it will fail because the default extent limit is far too small. This extent limit is a prebuilt table (from vgcreate) that cannot be changed. That's why vgcreate -e and -s options exist--you can size the table to a much larger value in order to add more disks at a later time.

[Alex Lavrov.]

Hello,

well, the issue was not vg itself, but the physical volume, so if the total number of physical extents won't be bigger than the value that was specified during vgcreate, no problem, but it's not possible anyway, so I guess this time we must add another physical volume and next time to plan the future a bit better ;)

[Pete Randall]

But that's one of the main features of a volume manager: the ability to combine physical volumes into an entity large enough to suit your needs with out being constrained by a single physical volume!


Pete

[Bill Hassell]

If I understand, you want to increase the size of a physical disk. Other than a fancy disk array (where the disks are already strung together as a giant storage unit), making a physical disk bigger isn't possible so vgcreate or vgextend has nothing to accomodate this unusual change.

[Alex Lavrov.]

Pete - yea, but I guess for the performance it's better to have small number of big volumes, than a big number of small ones ... Correct me if I'm wrong.

Bill - it's Netapp storage.

[Paul_481]

Hi Alex,

I think it would be better to have many small physical disk than few big disk. The reason is that it would be more flexible for you to assign them to different volume group.

Regarding performance, it is much better for data to be distributed to different disk to lessen disk I/O.

just my 2 cents.

Regards,
Paul

[Bill Hassell]

Small disks versus large...if you're talking about smart, large cache disk arrays, then there is little you can do to change performance. BUt for JBODs, the more disks you have and the more I/O cards you have, the higher the performance. That's why 4Gb and 9Gb drives are still in high demand. Put a couple of dozen 9Gb drives on several SCSI cards, put all the disks in a single volume group of 250Gb and performance will rival midrange disk arrays. The reason is simple: multiple I/Os can take place simultaneously. Change all those disks to a single 250Gb disk and no matter how fast the SCSI channel might be, only one I/O takes place at any one moment.

The concept of a volume group makes the allocation of files in various lvols very easy to spread out. Of course, there will always be corner cases where a particular arrangement of file access and I/O channels will be lower in performance, but as a general rule, more I/O channels are always better.

[Bill Hassell]

Ahhh, NAS is one giant disk storage box with a teeny-tiny pipe (LAN). NAS is great for low volume I/O but even a 100 Mbit LAN is too slow for a typical SCSI disk. A 100Mbit LAN = 5-7Mbyte/sec typical rate whereas a typical disk pushes data well over 10Mbytes/sec. From the system's point of view, each I/O just goes to/from one place: the LAN cable. Inside the array, a large disk and smart data allocation can mask delays from RAID 5 activities.

So for a NAS, performance with lots of smaller disks versus a few large ones won't be discernable. Keep your NAS on a private network--no other connections. And get a copy of Dave Olker's book on NFS for HP-UX.