— LiveStream

To expand an AIX JFS/JFS2 file system from new SAN storage you add the new LUN (hdisk) to the correct volume group with extendvg, confirm the freshly available physical partitions with lsvg, then grow the file system with chfs -a size=+<blocks>. This guide walks through the full, production-safe workflow to expand AIX file systems by mapping each mount point back to its logical volume, identifying the new disks presented by the storage array, extending the volume group, and growing the file system online with zero downtime.

The scenario is a classic one: a multi-partition application (here, a set of 16 MFS data file systems mounted under /biwab/dpNN/hNN/mfsdataNN) is filling up, and the storage team has just zoned and presented a batch of new LUNs from an enterprise array. Your job is to absorb that capacity cleanly into the Logical Volume Manager (LVM) and hand it to the file systems that need it.

The problem: file systems running low on space

A df -k review shows the data file systems trending toward full. In the source environment, fifteen of the sixteen file systems sat around 43-45% used, but one stood out:

Because these are mission-critical data file systems, you cannot wait until they hit 100% and start failing writes. The right move is to grow them ahead of need, using new capacity that the SAN team has already presented to the host as raw hdisk devices. On AIX, this is a routine, online operation thanks to LVM — no unmount and no reboot required.

Solution overview: how LVM expansion works on AIX

AIX storage is layered, and understanding the layers is the key to doing this safely. From the bottom up:

• Physical Volume (PV) — a disk the OS sees, e.g. hdisk50. A SAN LUN appears here.
• Volume Group (VG) — a pool of one or more PVs, e.g. BWARUabVG1. Space is allocated in fixed chunks called physical partitions (PPs).
• Logical Volume (LV) — a slice carved from the VG, e.g. lbiwab010000. It is built from logical partitions (LPs) that map to PPs.
• File system — the JFS or JFS2 mounted on top of the LV, e.g. /biwab/dp01/h00/mfsdata00.

To grow a file system you must therefore feed capacity up the stack: add the new PV to the VG so it has free PPs, then extend the LV and file system to consume those PPs. The high-level path is lspv → extendvg → lsvg → chfs. The sections below expand each step.

Step-by-step: expand AIX file systems from new LUNs

Run every command as root (or via sudo). Work on one file system at a time and verify before moving to the next.

1. Map each mount point to its logical volume and volume group. You need to know which VG owns the file system you intend to grow. The lslv command on the LV name reports its parent VG:

   lslv lbiwab010000

   Look at the VOLUME GROUP field in the output (for example BWARUabVG1). Repeat for each of the LVs you plan to expand. A faster way to get the LV-to-mount mapping for the whole group is lsvg -l <VG>, and to find which VG a mount belongs to you can also run df <mountpoint> to get the LV, then lslv <lv>.

2. Identify the newly presented LUNs. Freshly zoned LUNs show up as physical volumes with no Physical Volume Identifier (PVID) and no assigned VG. List them with:

   lspv

   New disks appear like hdisk50 none None — the none is the missing PVID and the None is the missing VG. If the disks do not appear at all, scan for new devices first with cfgmgr, then re-run lspv.

3. Confirm each LUN's identity and size. On systems using IBM SDD/SDDPCM multipathing (typical with the older IBM 2105 "Shark" arrays referenced here), verify the LUN with:

   pcmpath query device

   Check the Size column — in the source environment each LUN is 3.5 GB — and confirm every path shows state Y (open/healthy) across both fabrics. On modern AIX with native MPIO, use lspath -l hdisk50 and bootinfo -s hdisk50 (size in MB) instead. Confirming size and multipath health before you commit the disk avoids importing a half-zoned or single-pathed LUN.

4. Add the new LUN to the volume group. The command-line form is the cleanest and most repeatable:

   extendvg BWARUabVG1 hdisk50

   If you prefer the menu-driven tool, run smit vg → Set Characteristics of a Volume Group → Add a Physical Volume to a Volume Group, then press F4 to pick the VG name and again to pick the PV. If AIX warns that the disk "appears to belong to another VG" because of a stale PVID, and you are certain the LUN is new and empty, use extendvg -f — but only after double-checking, since forcing the wrong disk destroys data.

5. Verify the PV joined the VG. Confirm the new disk is now active in the group and contributing free partitions:

   lsvg -p BWARUabVG1

   The new disk should appear with PV STATE = active and a healthy FREE PPs count (for example hdisk50 active 26 26, meaning all 26 of its partitions are free).

6. Read the VG geometry: PP size and free PPs. You need two numbers — the physical partition size and the count of free PPs — to calculate how much you can grow the file system:

   lsvg BWARUabVG1

   In the source output, PP SIZE: 128 megabyte(s) and FREE PPs: 26. So the new usable capacity is 26 × 128 MB = 3,328 MB (about 3.25 GB).

7. Calculate the growth amount in 512-byte blocks. By default chfs -a size= expects a value in 512-byte blocks, not bytes. The conversion from free PPs is:

   blocks = FREE_PPs × PP_SIZE_MB × 1024 × 1024 / 512

   which simplifies to FREE_PPs × PP_SIZE_MB × 2048. For this VG: 26 × 128 × 2048 = 6,815,744 512-byte blocks. (Some older runbooks write this as PPs × PP_SIZE × 2 × 1024 and label the result "bytes" — the arithmetic gives the same 6,815,744, but the unit is 512-byte blocks, not bytes. Get this distinction right or your grow will be off by a factor of 512.)

8. Grow the file system online. Use the + prefix so the value is treated as an increment to the current size rather than an absolute target:

   chfs -a size=+6815744 /biwab/dp01/h00/mfsdata00

   The leading + is critical — size=6815744 without it would try to shrink a large file system to that absolute size (JFS2 supports shrink; JFS does not, and either way it is not what you want). On any reasonably modern AIX you can skip the block math entirely and let chfs do the conversion by passing a size suffix, e.g. chfs -a size=+3328M /biwab/dp01/h00/mfsdata00 or +3G. The grow is instantaneous and fully online; applications keep writing throughout.

9. Verify the new size. Confirm the file system actually grew:

   df -k /biwab/dp01/h00/mfsdata00

   Compare the 1024-blocks (total size) column before and after. You should see roughly 3,328 MB of additional space and a correspondingly lower percentage used.

10. Repeat per file system. For each remaining mount point, add its own dedicated new LUN to the matching VG and grow that file system. Keeping a one-LUN-per-file-system discipline (as the 16-way layout here implies) preserves the storage team's RAID and tiering design and keeps I/O balanced across the array.

Common pitfalls when you expand AIX file systems

Most failures in this workflow come from a handful of recurring mistakes. Watch for these:

• "Max number of PPs is 512" error during extend. Each LV has a per-LV cap on maximum logical partitions (default 512). If your grow pushes the LV past that limit, the extend fails. Raise the cap first with chlv -x 1024 <lv_name> (or higher), then re-run the chfs. This is the single most common blocker on large data LVs.
• Confusing blocks with bytes. As covered above, chfs -a size= defaults to 512-byte blocks. Mislabeling the unit is how runbooks accidentally request 512× too much or too little. When in doubt, use the M/G suffix.
• Forgetting the + sign. size=+N adds; size=N sets an absolute size. Omitting the plus on a production file system is a classic, dangerous slip.
• New LUNs not visible. If lspv does not list the new disks, run cfgmgr to rescan the SCSI/FC bus, and confirm with the storage team that the LUNs are zoned to both HBAs and mapped to the host's WWPNs.
• Single-pathed LUN. Adding a LUN that only has one healthy path leaves you exposed to a fabric failure. Verify all paths are up (pcmpath query device or lspath) before extendvg.
• Wrong volume group. Always map the mount point to its VG with lslv/lsvg -l first. Adding a disk to the wrong VG, or growing the wrong file system, wastes the new capacity and may force a tedious migratepv/reducevg cleanup.
• Forcing the extend blindly. Reserve extendvg -f for disks you have positively confirmed are new and empty. A stale PVID from a previously used LUN can otherwise be reused safely, but only after verification.

Verification checklist

After each file system grows, confirm the whole stack is consistent:

• lsvg -p <VG> — new PV is active; free PPs have dropped as expected.
• lsvg -l <VG> — the target LV shows the increased LP/PP count and open/syncd state.
• df -k <mount> — total blocks increased and percent-used fell.
• lsvg <VG> — STALE PVs and STALE PPs are both 0.
• Application logs — no I/O errors logged during the online grow; an errpt review shows no new disk or path errors.

A note on legacy hardware: IBM 2105 and SDDPCM

The storage in this example is an IBM 2105-800 (Enterprise Storage Server, codename "Shark"), multipathed with IBM SDD/SDDPCM. Both are long end-of-life: the 2105 was succeeded by the DS8000 family, and SDD/SDDPCM has been superseded by AIX's built-in MPIO with the AIXPCM path-control module. The LVM workflow above is unchanged on current AIX (7.2/7.3) with modern arrays such as IBM FlashSystem, DS8900F, or third-party SAN — only the multipath verification command differs. On a modern host, swap pcmpath query device for lspath, lsmpio, and bootinfo -s hdiskN, and prefer JFS2 over the legacy JFS shown in the source. If you are still running 2105/SDDPCM in production, the file-system process here is fully valid, but plan a migration to supported storage and MPIO.

Key Takeaways

• AIX storage is layered — PV → VG → LV → file system — and you grow capacity from the bottom up.
• The core sequence is lspv → extendvg → lsvg → chfs -a size=+N, all done online with no downtime.
• chfs -a size= defaults to 512-byte blocks; compute as FREE_PPs × PP_SIZE_MB × 2048, or just use a +NM/+NG suffix.
• Always include the + sign to add space, and verify multipath health before extendvg.
• If you hit "max number of PPs is 512," raise the LV cap with chlv -x 1024 <lv> before retrying.

Frequently Asked Questions

Can I expand an AIX file system without downtime?

Yes. Growing a JFS or JFS2 file system with chfs -a size=+N is a fully online operation. Applications keep reading and writing while the file system grows; no unmount or reboot is needed.

What is the difference between extendvg and chfs?

extendvg adds a new physical volume (LUN/hdisk) to a volume group so the group gains free physical partitions. chfs then consumes those free partitions to grow the logical volume and its file system. You almost always run them in that order.

How do I find which volume group a file system belongs to?

Run df <mountpoint> to get the logical volume name, then lslv <lv> and read the VOLUME GROUP field. Alternatively, lsvg -l <VG> lists every LV and its mount point for a given group.

Why does my chfs grow fail with "max number of PPs is 512"?

The logical volume has hit its per-LV maximum logical-partition limit. Increase it with chlv -x 1024 <lv_name> (set the new max as high as you need), then re-run the chfs -a size=+N command.

For more hands-on sysadmin and DevOps walkthroughs, subscribe to @explorenystream on YouTube.