— LiveStream

To extend SSA filesystems in AIX you discover the newly attached disks, add them to the right volume group with extendvg, then grow the JFS/JFS2 filesystem with chfs -a size=... while it stays mounted and online. This guide walks the full workflow end to end, fixes the common sizing mistakes, and shows you how to verify every step before and after the change.

The problem: a full filesystem on AIX SSA/SAN storage

A production AIX server is running low on space inside one or more application filesystems. The storage team has already carved out new LUNs on the disk subsystem (in the classic SSA era this was an IBM Serial Storage Architecture loop; on modern Power systems the same LUNs come from a SAN array such as an IBM 2105 “Shark” ESS or, today, a FlashSystem/DS8000 over Fibre Channel). The disks exist at the hardware layer, but AIX does not yet know about them, and the filesystems are not yet bigger.

The fix is a clean, repeatable Logical Volume Manager (LVM) procedure. AIX layers storage as physical volume (hdisk) → volume group (VG) → logical volume (LV) → filesystem (mount point). To extend SSA filesystems you push capacity up that stack: make the new disks visible, add them to the volume group that backs the filesystem, then enlarge the filesystem itself. Because JFS and JFS2 both support online growth, you can do all of this with the application running.

Before you start: prerequisites and a quick health check

Confirm the basics before touching anything. A few minutes here prevents an outage later.

• Root access. You need root (or RBAC authorization) to run cfgmgr, extendvg and chfs.
• LUNs presented and zoned. Ask the storage team to confirm the new LUNs are mapped to this host’s WWPNs and, for SAN, that Fibre Channel zoning is in place.
• Multipathing. On MPIO systems each LUN should appear as a single hdisk with multiple paths, not as duplicate disks. Verify later with lspath.
• Free space exists. Check the volume group has free physical partitions, or that you are adding disks to create them: run lsvg <vgname> and look at FREE PPs.
• A current backup. Take or confirm a recent mksysb/data backup. LVM operations are low-risk, but capacity changes are a good moment to be sure.

Step-by-step: how to extend SSA filesystems in AIX

The example below extends sixteen application filesystems (mount points like /biwab/dp01/h00/mfsdata00) by 1 GB each, using sixteen freshly created LUNs. The same steps scale to any number.

Step 1 — Snapshot the current disks, then run cfgmgr

Capture the disk list before the scan so you can prove exactly which devices are new. SSH to the host as root and run:

1. Record the current disks: lsdev -Cc disk > hdisks_before
2. Probe the hardware and configure new devices: cfgmgr
3. Record the disks again: lsdev -Cc disk > hdisks_after
4. Compare the two files: diff -w hdisks_before hdisks_after (the -w flag ignores whitespace differences)

The diff output lists only the newly discovered disks. In the example sixteen new MPIO Fibre Channel disks appeared:

> hdisk93  Available 05-08-02   IBM MPIO FC 2105
> hdisk94  Available 05-08-02   IBM MPIO FC 2105
> hdisk95  Available 05-08-02   IBM MPIO FC 2105
...
> hdisk108 Available 05-08-02   IBM MPIO FC 2105

The Available state means AIX has configured the disk and it is ready to use. If a disk shows Defined instead, re-run cfgmgr or check zoning and paths.

Step 2 — Confirm the new disks are free and fully pathed

Never assume a new disk is unused. Verify each one is not already in a volume group and has all expected paths:

1. List physical volumes and their VG membership: lspv. A new disk should show None in the VG column and usually none as its PVID until you assign it.
2. Check the paths for one of the new disks: lspath -l hdisk93. Every path should read Enabled.
3. Optionally confirm capacity: getconf DISK_SIZE /dev/hdisk93 (returns size in MB).

Only proceed with disks that are genuinely unallocated. Adding an in-use disk to the wrong VG can corrupt data.

Step 3 — Find which volume group backs each filesystem

You must add the new disk to the same volume group that already holds the logical volume for the target filesystem. Map each filesystem to its LV and VG. The fastest way is to read the LV behind the mount point:

1. Find the LV for a mount point from the filesystem stanza: lsfs /biwab/dp01/h00/mfsdata00 (the Name column is the device, e.g. /dev/lbiwab010000).
2. Display the LV details, which include its volume group: lslv lbiwab010000.

The lslv output identifies the owning VG and the partition geometry you will rely on for sizing:

LOGICAL VOLUME:   lbiwab010000      VOLUME GROUP:  BWARUabVG1
TYPE:             jfs               PP SIZE:       128 megabyte(s)
LPs:              51                PPs:           51
MOUNT POINT:      /biwab/dp01/h00/mfsdata00

Here the filesystem lives in volume group BWARUabVG1, the physical partition (PP) size is 128 MB, and the LV currently has 51 logical partitions. Note the PP size now — it drives the math in Step 5.

Step 4 — Add the new disk to the volume group (extendvg)

With the VG name and a free hdisk identified, add the disk so the VG gains free partitions. Use SMIT or the command line; both do the same thing.

Command line (preferred for scripting):

1. Add the disk: extendvg BWARUabVG1 hdisk93
2. Confirm the new free space: lsvg BWARUabVG1 and check that FREE PPs increased.

SMIT (menu-driven): run smitty extendvg, then on the Add a Physical Volume to a Volume Group panel set:

• Force the creation of a volume group? = no
• VOLUME GROUP name = BWARUabVG1
• PHYSICAL VOLUME names = hdisk93

Press Enter to apply. If extendvg complains that the PP size of the new disk is too small for this VG, the disk is larger than the VG’s maximum capacity per disk — a standard (non-Big, non-Scalable) VG has a 1016 PP-per-disk limit. In that case use chvg -t to raise the factor, or recreate the VG as a Scalable VG.

Step 5 — Calculate the growth, then extend the filesystem (chfs)

Adding the disk only gave the VG more free partitions; the filesystem still reports its old size. Now grow the filesystem itself with chfs. The -a size=+N syntax adds capacity, where N is in 512-byte blocks — this is the single most common place people get the number wrong.

To add 1 GB, convert gigabytes to 512-byte blocks:

1 GB = 1024 MB = 1024 x 1024 KB = 1024 x 1024 x 2 (512-byte blocks)
     = 2,097,152 blocks

1. Extend by 1 GB: chfs -a size=+2097152 /biwab/dp01/h00/mfsdata00

The leading + means add to the current size; without it the value is treated as the new absolute size, which can unexpectedly shrink the request. On JFS2 you can skip the block math entirely and use human units, which is far less error-prone:

chfs -a size=+1G /biwab/dp01/h00/mfsdata00

AIX rounds the request up to a whole number of physical partitions. With a 128 MB PP size, 1 GB equals exactly 8 PPs (8 x 128 MB = 1024 MB), so the LV grows by 8 logical partitions.

Step 6 — Repeat for every filesystem

Run Steps 3–5 for each remaining mount point, pairing each filesystem with one of the new disks. For sixteen filesystems and sixteen LUNs the mapping is one disk per filesystem; for a single large VG you might instead add a few big disks and extend many filesystems from the shared free pool. Scripting the loop avoids transcription errors:

for fs in /biwab/dp01/h00/mfsdata00 /biwab/dp01/h01/mfsdata01; do
    chfs -a size=+1G "$fs"
done

Common pitfalls when you extend SSA filesystems in AIX

These are the mistakes that turn a five-minute change into an incident.

• Wrong size units. chfs -a size= on JFS counts 512-byte blocks, not MB or GB. Asking for size=+1024 adds only 512 KB, not 1 GB. Use the +2097152 block math or the JFS2 +1G shorthand.
• Forgetting the plus sign. size=2097152 sets an absolute size; size=+2097152 adds. Omitting + on a large filesystem can request a shrink, which JFS will refuse and JFS2 may attempt.
• Adding the disk to the wrong VG. Always derive the VG from lslv/lsfs for the exact mount point. A guess can scatter an LV across unrelated storage.
• No free PPs. If extendvg was skipped or the disk was too small, chfs fails with “not enough free physical partitions.” Confirm FREE PPs in lsvg first.
• Treating duplicate paths as new disks. Without proper MPIO, one LUN can appear as several hdisks. Adding them all double-counts capacity and risks corruption. Verify with lspath.
• Ignoring the PP-per-disk limit. Classic VGs cap at 1016 PPs per disk; large LUNs need chvg -t or a Scalable VG.

Verification: confirm the filesystem actually grew

Trust nothing until you have checked it three ways. After each chfs, confirm the change landed.

1. Filesystem level: df -g /biwab/dp01/h00/mfsdata00 shows the new total size in GB and remaining free space.
2. Logical volume level: lslv lbiwab010000 — the PPs value should have increased by the expected count. In the example it went from 51 to 59 PPs, exactly +8 (8 x 128 MB = 1024 MB = 1 GB).
3. Volume group level: lsvg BWARUabVG1 confirms the new disk is counted and shows how many free PPs remain for the next extension.

The LV before-and-after comparison is the cleanest proof:

If the numbers match your intent across all three layers, the extension is complete and the application can keep writing without a restart.

A note on legacy SSA and the modern equivalent

Serial Storage Architecture (SSA) was IBM’s 1990s–2000s loop-based disk technology, and the IBM 2105 array in this example is the discontinued Enterprise Storage Server (“Shark”). Both are end-of-life. The good news is that the AIX-side procedure has not changed: the LVM commands — cfgmgr, lspv, extendvg, lslv, chfs — are identical whether the disks come from old SSA, an ESS, a DS8000, a FlashSystem array, or virtual disks served by VIOS. On current AIX 7.2/7.3 systems prefer JFS2 (which supports shrinking, larger files, and the friendly +1G size syntax) and consider smitty fs or smitty jfs2 for the menu-driven path. The concepts — disk to VG to LV to filesystem — are timeless.

Key Takeaways

• Discover first: snapshot disks with lsdev -Cc disk, run cfgmgr, then diff -w to isolate exactly the new hdisk devices.
• Map filesystem to VG using lsfs and lslv before adding any disk — the new disk must join the volume group that backs the target mount point.
• extendvg adds capacity to the VG; chfs grows the filesystem — you need both, in that order.
• Get the units right: JFS size= is in 512-byte blocks (1 GB = +2097152), or use the JFS2 +1G shorthand; always include the leading +.
• Verify at three layers with df -g, lslv (PP count) and lsvg — a +8 PP jump at 128 MB PP size equals exactly 1 GB.

Frequently Asked Questions

Can I extend an AIX filesystem while it is mounted and in use?

Yes. Both JFS and JFS2 support online growth, so chfs -a size=+... works while the filesystem is mounted and the application is running. No unmount, reboot, or downtime is required to add space.

What is the correct chfs size value to add 1 GB?

On JFS the value is in 512-byte blocks: 1 GB = 1024 x 1024 x 2 = 2,097,152, so run chfs -a size=+2097152 /mount/point. On JFS2 you can use the simpler unit form chfs -a size=+1G /mount/point. Always keep the leading + to add rather than set an absolute size.

What is the difference between extendvg and chfs?

extendvg adds a physical disk to a volume group, increasing the pool of free physical partitions. chfs consumes some of those free partitions to enlarge a logical volume and its filesystem. If the VG already has free space, you can skip extendvg and run chfs directly.

Why didn’t my filesystem grow after extendvg?

Because extendvg only enlarges the volume group, not the filesystem. You must still run chfs -a size=+... on the specific mount point. Confirm the VG has free PPs with lsvg, then extend and verify with df -g and lslv.

For more hands-on AIX, Linux, and storage walkthroughs, subscribe on YouTube @explorenystream.