If possible, for easier system management and better performance, the default volume group, rootvg, should consist of only the physical volume on which the operating system is initially installed. Maintaining only operating systems in the rootvg is a good decision because operating system updates, reinstallations, and crash recovery can be accomplished without endangering user data. Updates and reinstallations can be done more quickly because only the operating system is included in the changes.
One or more other volume groups should be defined for the other physical volumes that hold the user data. Having user data in alternate volume groups allows easier exporting of that data to other systems.
Place a highly active file system on one disk and the log for that file system on another if the activity would generate a lot of log transactions (see Reorganizing JFS Log and Log Logical Volumes). Cached devices (such as solid-state disks, SSA with Fast Write Cache, or disk arrays with write-cache) can provide for much better performance for log logical volumes (JFS log or database logs).
Although mirroring is common for customer data, particularly in database environments, it is used less frequently for system volumes.
In mirroring, when a write occurs, it must occur to all logical volume copies. Typically, this write will take longer than if the logical volume was not mirrored. Mirroring can also cause additional CPU overhead, because two disk I/Os take more instructions to complete than one. It is important to understand the layout of the rootvg logical volumes so one can guess where problems might exist when mirroring the rootvg logical volumes.
Looking at logical volumes typically found in rootvg, we expect most of the files in /, including the heavily used /usr/bin where many executable programs reside, to be read-mostly data. The paging space should have writes only if the amount of physical memory in the system is insufficient to hold the current level of activity. It is common for systems to page from time to time, but sustained heavy paging usually leads to poor response time. The addition of physical memory generally resolves this issue.
The /tmp and /var file systems do see file-write activity for many types of applications. Applications, such as the compiler, often create and write temporary files in the /tmp directory. The /var directory receives files destined for mail and printer queues. The jfslog is essentially write-only during normal operation. Of the remaining file systems, perhaps only the /home directory is active during normal operation. Frequently, user home directories are placed in other file systems, which simplifies rootvg management.
The rootvg can be mirrored by mirroring each logical volume in rootvg with the mklvcopy command; or in AIX 4.2.1 and later, rootvg can be mirrored using the mirrorvg command.
By default, the mirrorvg command uses the parallel scheduling policy and leaves write-verify off for all logical volumes. It does not enable mirror-write consistency for page space. It does enable mirror-write consistency for all other logical volumes. Place logical volumes that are written to frequently close to the outer edge of the disk to minimize seek distance between the logical volume and the mirror-write consistency cache.
The caveat to mirroring rootvg not significantly affecting performance is that, if paging space is mirrored, the slowdown is directly related to paging rate. So systems that are configured to support very high paging rates, with paging spaces on rootvg, might not want to implement rootvg mirroring.
In summary, mirrored rootvg might be worth considering if your workload does not have high sustained paging rates.