Secrets of an AIX Administrator, Part 2: File Systems

On the list of the most common activities that AIX systems administrators perform, file system maintenance comes right after user ID maintenance and password resets. I can’t count the number of times I’ve created, grown, shrunk, or deleted file systems in the course of my professional career. When you think about it, this makes sense: Almost every user needs space to store his or her data.

AIX’s flexibility for managing data comes with a downside: There are many ways to make an error in file system maintenance that will set the stage for future problems on the server. It takes only one or two commands to make a server practically impossible to grow, so that you can’t keep up with demands for additional places for data. Growing a file system the wrong way—for example, growing an IBM PowerHA file system on a server without using the PowerHA command set—can also create more work in the long run. To help you avoid file system maintenance mistakes that could result in inefficiencies on your server, this article offers some pearls of file system wisdom that I’ve acquired over the years.

Use the Root Volume Group for Rootvg Data Only

The most common mistake administrators—especially novice admins—make is to put a file system inside the root volume group (rootvg) or to use space that’s within the rootvg for application-related work. Here are the three big reasons you shouldn’t do this:

• If you’re using internal disks, you’ll be more limited as to how large you can make your file systems.
• In the event that the file systems need to be exported to another system, you’ll wind up exporting your entire rootvg.
• Putting a file system within rootvg can make backups performed using mksysb or other AIX backup utilities exceedingly large.

I recommend using rootvg space only for applications in limited circumstances, such as small web servers, personal AIX systems, and temporary testing environments.

Break Down Volume Groups

When you begin to plan a Power Systems server environment, think about how to use your disk space efficiently and purposefully. Separate the data into volume groups according to guidelines such as how dynamically VGs will change, types of data and access levels, and types of storage. For example, AIX 6.1 and 7.1 provide a new flag, -X, for the mkvg and chvg commands, which can restrict VGs to using a certain type of storage, such as solid-state drive (SSD) disks, thereby preventing a mixed-storage environment that could cause a hit on the server’s I/O. Use these tools with foresight to design a maintainable system.

Use JFS2 and Scalable VGs

The more modern versions of AIX include two features of the Logical Volume Manager (LVM) that I recommend be used almost everywhere. The first is scalable volume groups. In the past, AIX had limitations as to how many physical volumes could be in a volume group, how large the volume group could get, and how large the physical partition size could be. Scalable volume groups eliminate almost every reasonable constraint previously associated with managing volume groups.

The second feature is the enhanced journaled file system structure, better known as JFS2. Just as scalable volume groups improved management of larger disks, JFS2 took the limitations of JFS and rendered them obsolete by permitting file systems to grow larger than the 2TB limit. JFS2 also gave us better tools, such as the ability to shrink the size of a file system. If you create your volume groups and file systems using these two features, you’ll eliminate 90 percent of the growth and sustainability problems that existed just a decade ago.

Keep Physical Volumes the Same Size Whenever Possible

Aesthetically speaking, there’s nothing worse than pulling up information on the physical volumes in a volume group and seeing all sorts of random disk sizes. I’ve seen servers with disks ranging from 20GB to 500GB—all in the same volume group. This discrepancy in sizes can be caused by disks being mixed and matched across local and SAN storage, people responding to emergency file system growth requests, and sloppy SAN administrators. However, this kind of non-uniform disk layout can have other implications, such as limiting growth (e.g., a logical volume’s inter-disk policy is reached) and impacting I/O (e.g., a large, hot disk takes 80 percent or more of the I/O for a volume group).

I recommend working with SAN administrators and those in charge of storage to come up with a uniform disk-size policy for volume groups. Set the physical volume size to something appropriate—for example, 50GB—and stick to that size policy. If you set the policies for your logical volumes to be striped across all the disks (assuming there’s some type of RAID configuration on the back end, as is the case in most SAN environments), you’ll avoid creating any hot spots. This configuration has the added benefit of making the root disk easily visible when you’re booting through a System Management Services (SMS) menu if you pick a unique size, such as 48GB, for its disks.

Simple Steps to Better File Management

By following my advice, you’ll find that once-troublesome file-system requests will become one of the easiest tasks you to perform. The tips I provided will also help you in the long run with patching your servers.

Courtesy Christian Pruett &  POWER IT Pro.