Good Practice in lvol maintenance

[Anthony Villanueva]

Hi,

I was just wondering what is the best practice when it comes to utilizing disk space for logical volumes and volume groups.

For example, I have 6x32GB disk drives configured with RAID1. Is it best to create a filesystem(1 volume group, 1 logical volume) that utilizes the full 32GB of each hard disk? What are the pros and cons of creating several logical volumes for each volume group? Lastly, is there a recommended size for each logical volume for optimum performance?

[Patrick Wallek]

It really depends on what your needs are. Unless your application requires a large LV, I personally would NOT create 1 large LV for each disk. There really are no advantages to creating 3 VGs with 1 LV each or 1 VG with 3LVs. It just really doesn't matter.

You CAN create the LVs so that each LV is on a different disk. You just specify the disks you want the LV on when you issue the lvcreate command.

Create the LVs slightly larger than you think you might need them. You can always make them larger later if need be. If you have the Advance JFS / Online JFS product then you don't even have to unmount the filesystem to do it.

[Anthony Villanueva]

Thanks patrick.

Forgive me for being ignorant, how do i check if i have the Advance JFS/Online JFS? I'm using a RP5405 server.

[Sunil Sharma_1 · Accepted solution]

hi,

#swlist -l product|grep -i online

If you have online JFS installed it will return like this

OnlineJFS B.11.11 Online features of the VxFS File System


Sunil

[Bill Hassell]

LVM is designed to take a micro-managed technique (thinking in physical disk terms) and removing all the effort by treating the VG space as a single entity. You then carve up the space without regard to space. Just create the lvol size that your data needs, including any growth. Even then, lvols can be extended although the additional extents may come from a non-sequential location.

There is no such thing as an optimal size for performance. The reason is that you have not specified any access patterns (reads writes block offsets, etc) which are generally impossible to specify. LVM is a bookeeping tool and neither the extent size of the lvol nor the total size of the lvol affect performance. All you have to do to ruin performance is write an application that reads two widely separated points on the disk. With a filesystem, this may be very difficult or very easy to create. Trying to position the data goes back to the days of punched cards and papertape. With HP-UX, the buffer cache and well-written application programs have orders of magnitude more effect than playing with lvols.

The most important task for good performance on large (dozens of Gbytes) lvols is not to have millions of files in a single directory. This is not an LVM issue, it is the inevitable requirement of managing massive file farms. It is much simpler to pick the busiest files and move then to a physically separate disk. More I/O channels = much higher throughput. A 32Gb is much slower than two 16Gb disks, and really slow compared to four 9Gb disks, assuming that each disk has it's own controller.

Keep you executables and config files on one set of disks, your data areas on another set and a third set for indexes and temp areas, ideally with 3 separate I/O paths to the disks.

[Anthony Villanueva]

I understand that the size of the volumes depends on my usage(data, applications and different environment) and future expansion.