Here’s an example of converting
rootvg file systems from JFS to JFS2 using alt_disk_copy.

My lab system was migrated from AIX
5.3 to 7.1 via nimadm. Unfortunately, nimadm does not convert JFS file
systems to JFS2 during the migration. So, in this case, even though I’ve
migrated to AIX 7.1 (which is a good thing) I’m still left with legacy JFS file
systems in rootvg.

And because the AIX 5.3 version of
the alt_disk_copy command does not
have the –T option, I can’t convert my JFS file systems to JFS2 before I
migrate to AIX 7.1. So my best option is to migrate to AIX 7.1 then convert
rootvg to JFS2 file systems. A few hops in the process but it’s good enough.

aixlpar1 : /
# lsvg -l rootvg

rootvg:

LV NAMETYPELPsPPsPVsLV STATEMOUNT POINT

hd5boot111closed/syncdN/A

hd6paging32321open/syncdN/A

hd8jfslog111open/syncdN/A

hd4jfs441 open/syncd/

hd2jfs29291open/syncd/usr

hd9varjfs20201open/syncd/var

hd3jfs1641641open/syncd/tmp

hd1jfs441open/syncd/home

hd10optjfs441open/syncd/opt

localjfs441open/syncd/usr/local

loglvjfs441open/syncd/var/log

hd7sysdump991open/syncdN/A

hd71sysdump991open/syncdN/A

hd11adminjfs221open/syncd/admin

aixlpar1 : /
# oslevel -s

7100-01-01-1141

I clone rootvg to a spare disk using
alt_disk_copy and the –T flag (which will convert the file
systems to JFS2). The process converts the file systems to JFS2, as shown in
the section below (highlighted in green).

aixlpar1 : /
# alt_disk_copy
-d hdisk1 -T

Source boot
disk is: hdisk2

jfs2j2: Current data file
/image.data moved to /image.data.acct.save.3735802.

Before I reboot the system on the
alternate rootvg I verify that the cloned volume group now contains JFS2 file
systems only. I “wake up” the altinst_rootvg and run the lsvg command to confirm the file system is correct. I then put the
altinst_rootvg to “sleep”, reboot the system and verify all rootvg file systems
are mounted as jfs2.

aixlpar1 : /
# alt_rootvg_op -W -d hdisk1

Waking up
altinst_rootvg volume group ...

aixlpar1 : /
# lsvg -l altinst_rootvg

altinst_rootvg:

LV NAMETYPELPsPPsPVsLV STATEMOUNT POINT

alt_hd5boot111closed/syncdN/A

alt_hd6paging32321closed/syncdN/A

alt_hd8jfs2log111open/syncdN/A

alt_hd4jfs2441open/syncd/alt_inst

alt_hd2jfs229291open/syncd/alt_inst/usr

alt_hd9varjfs220201open/syncd/alt_inst/var

alt_hd3jfs21641641open/syncd/alt_inst/tmp

alt_hd1jfs2441open/syncd/alt_inst/home

alt_hd10optjfs2441open/syncd/alt_inst/opt

alt_localjfs2441open/syncd/alt_inst/usr/local

alt_loglvjfs2441open/syncd/alt_inst/var/log

alt_hd7sysdump991closed/syncdN/A

alt_hd71sysdump991closed/syncdN/A

alt_hd11adminjfs2221open/syncd/alt_inst/admin

aixlpar1 : /
# alt_rootvg_op -S altinst_rootvg

Putting
volume group altinst_rootvg to sleep ...

forced
unmount of /alt_inst/var/log

forced
unmount of /alt_inst/var

forced
unmount of /alt_inst/usr/local

forced
unmount of /alt_inst/usr

forced
unmount of /alt_inst/tmp

forced
unmount of /alt_inst/opt

forced
unmount of /alt_inst/home

forced
unmount of /alt_inst/admin

forced
unmount of /alt_inst

Fixing LV
control blocks...

Fixing file
system superblocks...

aixlpar1 : /
#

; Reboot on
the alternate rootvg hdisk

aixlpar1 : /
# uptime

10:18AMup 1 min,1 user,load average: 0.32, 0.09, 0.03

aixlpar1 : /
# lspv

hdisk100c342c637f21a59rootvgactive

hdisk200c342c6161c6b47old_rootvg

aixlpar1 : /
# df

Filesystem512-blocksFree %UsedIused %Iused Mounted on

/dev/hd452428841156822%30407% /

/dev/hd2380108853717686%3408935% /usr

/dev/hd9var262144024135208%35542% /var

/dev/hd321495808214763121%1101% /tmp

/dev/hd15242885224561%901% /home

/proc-----/proc

/dev/hd10opt52428826656050%513315% /opt

/dev/local5242884953206%2491% /usr/local

/dev/loglv5242885220401%491% /var/log

/dev/hd11admin2621442613841%71% /admin

aixlpar1 : /
# lsvg -l rootvg

rootvg:

LV NAMETYPELPsPPsPVsLV STATEMOUNT POINT

hd5boot111closed/syncdN/A

hd6paging32321open/syncdN/A

hd8jfs2log111open/syncdN/A

hd4jfs2441open/syncd/

hd2jfs229291open/syncd/usr

hd9varjfs220201open/syncd/var

hd3jfs21641641open/syncd/tmp

hd1jfs2441open/syncd/home

hd10optjfs2441open/syncd/opt

localjfs2441open/syncd/usr/local

loglvjfs2441open/syncd/var/log

hd7sysdump991open/syncdN/A

hd71sysdump991open/syncdN/A

hd11adminjfs2221open/syncd/admin

===

The message “filesystem
not converted” (below)
is not related to the JFS to JFS2 conversion. This messge refers to whether or
not the file system needs to be changed to use Variable Inode Extents (VIX).
This is the default setting for JFS2 file systems.

Why would I want to convert rootvg
to JFS2 anyway? Well for starters, it’s generally considered best practice to
use JFS2 as it offers several performance & scalability enhancements over
JFS. For example, you cannot create files greater than 2GB on JFS, unless the
file system was created as “large (big) file” enabled; jfs file systems in
rootvg were never created as large file enabled.

Another reason…..eventually JFS will
be retired.

Here’s an example of a potential
problem with JFS in rootvg. You try to create a file of a size greater than 2GB
in /tmp (type jfs). Even though the ulimit settings are not restricting the
creation of a file of this size, the JFS file system will not allow it. The
file creation process fails. The bf attribute
for the /tmp file system is set to false.
This indicates the file system is not “large file” enabled.

You may find
yourself in a situation where you’d like to convert a VG to scalable.

For example,
you might start off with a normal VG i.e. one that can support a maximum of 256
LVs and 32 PVs.

# mkvg -s
512M -y myvg hdisk5

myvg

# lsvg myvg

VOLUME
GROUP:myvgVG IDENTIFIER:00f6027300004c0000000133aa24d1f6

VG
STATE:activePP SIZE:512 megabyte(s)

VG
PERMISSION:read/writeTOTAL PPs:99 (50688 megabytes)

MAX LVs:256FREE PPs:0 (0 megabytes)

LVs:1USED PPs:99 (50688 megabytes)

OPEN
LVs:1QUORUM:2 (Enabled)

TOTAL
PVs:1VG DESCRIPTORS: 2

STALE
PVs:0STALE PPs:0

ACTIVE
PVs:1AUTO ON:yes

MAX PPs per
VG:32512

MAX PPs per
PV:1016MAX PVs:32

LTG size
(Dynamic): 256 kilobyte(s)AUTO
SYNC:no

HOT SPARE:noBB POLICY:relocatable

PV
RESTRICTION:none

Sometime
later you discover you need to grow the volume group and add more hdisks. But
you can’t because you’ve reached the maximum PV limit of 32.

You examine the chvg man page and discover the –G
flag! Of course you take note of the special considerations when converting to
scalable.

Changes the volume group to
Scalable VG format. This can accommodate up to 1024 physical volumes and 4096
logical volumes. Notes:

1The -G flag cannot be used if there are any stale physical partitions.

2Once the volume group is converted, it cannot be imported into AIX(R)
5.2 or lower versions.

3The -G flag cannot be used if the volume
group is varied on.

4There must be enough free partitions
available on each physical volume for the VGDA expansion for this operation to
be successful.

5Since the VGDA resides on the edge of the disk and it requires
contiguous space for expansion, the free partitions are required on the edge of
the disk. If those partitions are allocated for user usage, they will be
migrated to other free partitions on the same disk. The rest of the physical partitions will be
renumbered to reflect the loss of the partitions for VGDA usage.
This will change the mappings of the logical to physical partitions in all the
PVs of this VG. If you have saved the mappings of the LVs for a potential
recovery operation, you should generate the maps again after the completion of
the conversion operation. Also, if the backup of the VG is taken with the map
option and you plan to restore using those maps, the restore operation may fail
since the partition number may no longer exist (due to reduction). It is
recommended that backup is taken before the conversion, and right after the
conversion if the map option is utilized.

6Because the VGDA space has been increased
substantially, every VGDA update operation (creating a logical volume, changing
a log ical volume, adding a physical volume, and so on) may take considerably
longer to run.

Excellent, I
can convert my VG to scalable.

The volume
group must be varied off before it can be converted.

# chvg -G
myvg

0516-1707
chvg: The
volume group must be varied off during conversion to

scalable volume group format.

0516-732
chvg: Unable to change volume group myvg.

# umount
/myfs

# lsvg -l
myvg

myvg:

LV NAMETYPELPsPPsPVsLV STATEMOUNT POINT

mylvjfs299991closed/syncd/myfs

# varyoffvg
myvg

There must
be enough free PPs in the volume group (on each hdisk) in order for the
conversion to work. If there aren’t then you’ll see this error:

# chvg -G
myvg

0516-1214
chvg: Not
enough free physical partitions exist on hdisk5 for the

expansion of the volume group
descriptor area. Migrate/reorganize to freeup

1 partitions and run chvg again.

0516-732
chvg: Unable to change volume group myvg.

In this
example, we vary on the VG again, and shrink the file system by 1 PP, giving us
1 PP free in the volume group. Remember, “There
must be enough free partitions available on each physical volume for the VGDA
expansion for this operation to be successful.”

# varyonvg
myvg

# chfs -a
size=-512M /myfs

Filesystem
size changed to 102760448

Inlinelog
size changed to 196 MB.

# lsvg myvg

VOLUME
GROUP:myvgVG IDENTIFIER:00f6027300004c0000000133aa24d1f6

VG
STATE:activePP SIZE:512 megabyte(s)

VG
PERMISSION:read/writeTOTAL PPs:99 (50688 megabytes)

MAX
LVs:256FREE PPs:1 (512 megabytes)

LVs:1USED PPs:98 (50176 megabytes)

OPEN
LVs:0QUORUM:2 (Enabled)

TOTAL
PVs:1VG DESCRIPTORS: 2

STALE
PVs:0STALE PPs:0

ACTIVE
PVs:1AUTO ON:yes

MAX PPs per
VG:32512

MAX PPs per
PV:1016MAX PVs:32

LTG size
(Dynamic): 256 kilobyte(s)AUTO
SYNC:no

HOT
SPARE:noBB POLICY:relocatable

PV
RESTRICTION:none

The VG is
varied off again.

# varyoffvg
myvg

# lsvg -o

rootvg

We convert
the VG to scalable.

# chvg -G
myvg

0516-1224
chvg: WARNING, once this operation is completed, volume group myvg

cannot be
imported into AIX 5.2 or lower versions. Continue (y/n) ? y

0516-1216
chvg: Physical partitions are being migrated for volume group

descriptor
area expansion.Please wait.

0516-1712 chvg: Volume group myvg
changed.myvg can include up to 1024
physical volumes with 2097152 total physical partitions in the volume group.

We vary on
the volume group and check that it is now scalable. You’ll notice that we’ve
now lost that free PP in the VG as it has been used in the conversion process.

# varyonvg
myvg

# lsvg myvg

VOLUME
GROUP:myvgVG IDENTIFIER:00f6027300004c0000000133aa24d1f6

VG
STATE:activePP SIZE:512 megabyte(s)

VG
PERMISSION:read/writeTOTAL PPs:98 (50176 megabytes)

MAX LVs:256FREE PPs:0 (0 megabytes)

LVs:1USED PPs:98 (50176 megabytes)

OPEN
LVs:0QUORUM:2 (Enabled)

TOTAL
PVs:1VG DESCRIPTORS: 2

STALE
PVs:0STALE PPs:0

ACTIVE
PVs:1AUTO ON:yes

MAX PPs per
VG:32768MAX PVs:1024

LTG size
(Dynamic): 256 kilobyte(s)AUTO SYNC:no

HOT
SPARE:noBB POLICY:relocatable

PV
RESTRICTION:none

If you are
unable to free up a physical partition on a your hdisk (or hdisks) then you may
need to use a tool like migratelp to
move logical partitions around in order to free up some space. From the migratelp man page:

migratelp Command

Purpose

Moves allocated logical partition
from one physical partition to another physical partition on a different
physical volume.