Volume Management and System Tuning

Henry Newman

This month, I’ll explain how and why to tune volume managers. In my previous columns, I’ve examined how application I/O using C Library I/O has a great impact on how much work the system has to do. In my most recent column, I specifically covered how applications I/O from system calls impact the system. The extra work caused by applications can be reduced or eliminated given how the volume managers are configured. By the same token, a poor volume can add to I/O overhead in the system and significantly reduce system performance. In both cases, the volume manager is a significant part of the equation. So this month, I will discuss aspects of tuning the system for volume managers.

System Tuning

One of the keys to tuning a system is gaining an understanding of the I/O path through the system. Many operating systems, volume managers, and file systems have limitations on the size of the I/O requests that can be made to the system. On Solaris, for example, by default, the largest physical request that can be made is 128 KB. This can be changed by a modification to /etc/system to add:

set maxphys= "value in decimal, octal or hexadecimal"

To set maxphys to 8 MB, you add to /etc/system:

set maxphys=8388608

or

set maxphys=0x800000

In Solaris, each of the device drivers relating to SCSI I/O sd (SCSI Device Driver), ssd (Fibre Channel Device Driver), and st (Tape Device Driver) supports an upper limit of 1 MB for a transfer size, even though maxphys from /etc/system is set to a value larger than 1 MB. Each of these device drivers must be changed if you want to make I/O requests over 1 MB for devices used by that driver.

Therefore, the largest value that can be transferred from an application to or from the system will be 1 MB without changes to the device driver — even if you have made changes in /etc/system.