Manually Editing /etc/filesystems Can Cause Issues

As an AIX administrator, editing files directly is part of the course. However, some system files require a bit of caution when editing. Let’s look at one example, the /etc/filesystems.

When you create a file system, the underlying logical volume (LV) is associated with the file system in the Object Database Manager (ODM), or more correctly, it’s logged into the Volume Group Descriptor Area (VGDA) of the hdisks concerned and the logical volume control block (LVCD). So far, so AIX. However, when doing file system maintenance—like changing the underlying LV, maybe by previously doing a cplv to copy the LV to a new LV that could reside in another volume group—you could get lazy and directly edit /etc/filesystems to change the association on the underlying LV. This can cause issues, especially if you need to export and import the volume group (VG) to a different host. You will have problems mounting your file system.

When you manually edit the /etc/filesystems file, the ODM doesn’t get updated. It’s that simple. It will think you still have the original LV in place and try to mount the file system. So, you should either use the chfs command or change via SMIT when changing the associated underlying LV. Confused on why this is so? Let me show you an example.

Confirm the File System and its LV

First let’s create a file system called holding inside the VG hold_vg, the underlying LV for the file system fslv04, which resides on hdisk1.

# crfs -v jfs2 -g hold_vg -m /holding -A yes -a size=1G
File system created successfully.
1048340 kilobytes total disk space.
New File System size is 2097152

# mount /holding

Now let’s check the VG:

# lsvg -l hold_vg
hold_vg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1       1       1    open/syncd    N/A
fslv04              jfs2       64      64      1    open/syncd    /holding

Now check the /etc/filesystems for the file system layout:

 grep -p "/holding" /etc/filesystems
/holding:
        dev             = /dev/fslv04
        vfs             = jfs2
        log             = /dev/loglv01
        mount           = true
        account         = false

We can confirm that fslv04 is associated with /holding in a few ways. We can query the filesystem using the lsjfs2 command like so (in the following commands quite a lot of the output has been truncated for readability reasons):

# lsjfs2 /holding
/holding:/dev/fslv04

You can also use the getlvcb command. Note in the following command, it also informs us on the creation time of the file system, which is quite handy to know.

# getlvcb -AT fslv04
lvname = fslv04 
         label = /holding
time created  = Mon May 11 11:04:47 2015
 time modified = Mon May 11 11:04:49 2015

We can also interrogate the ODM:

# odmget -q "name=fslv04" CuAt
CuAt:
        name = "fslv04"
        attribute = "label

And last but not least, you can use the readvgda command, as the LV resides on hdisk1, to query that disk:

# readvgda -l hdisk1
============= B: LV fslv04 =============
MOUNT POINT:        DEV                    LABEL:          /holding

Copy the LV and Manually Edit /etc/filesystems

Now that you’ve confirmed that confirm that fslv04 is the LV associated with the file system /holding, let’s now use cplv to copy fslv04 to a new LV called x_fslv04, then review the VG layout:

# umount /holding
# cplv -y x_fslv04 fslv04
cplv: Logical volume fslv04 successfully copied to x_fslv04 .
# lsvg -l hold_vg
hold_vg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1       1       1    closed/syncd  N/A
fslv04              jfs2       64      64      1    closed/syncd  /holding
x_fslv04            jfs2       64      64      1    closed/syncd  N/A

At this point, I manually edit /etc/filesystems and point x_fslv04 to /holding (thus removing fslv04). Post editing, it looks like the following and gets mounted using the newly copied LV:

# grep -p "/holding" /etc/filesystems
/holding:
        dev             = /dev/x_fslv04
        vfs             = jfs2
        log             = /dev/loglv01
        mount           = true

# mount /holding

Compare this output to the previous /etc/filesystems and you can see we are indeed now using the copied LV (x_fslv04) for the filesystem /holding.

Here Comes the Sting!

Now let’s cause a headache for ourselves. First, export the VG and re-import it. Then query to see if x_fslv04 is still associated with /holding.

# unmount /holding
# varyoffvg hold_vg
# exportvg hold_vg


# importvg -y hold_vg hdisk1
# mount /holding

Now let’s review the VG hold_vg:

# lsvg -l hold_vg
hold_vg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1       1       1    open/syncd    N/A
fslv04              jfs2       64      64      1    open/syncd    /holding
x_fslv04            jfs2       64      64      1    closed/syncd  /holding

Oops! We’re back to square one, with /holding mounted using the original LV fslv04.

Let’s query the LVs:

# getlvcb -AT fslv04
         lvname = fslv04 
         label = /holding

# getlvcb -AT x_fslv04
         lvname = fslv04 
         label = /holding

We have fslv04 and x_fslv04 both pointing to /hold. How do we get out of this pickle? To start, we should have either done the LV change for associated file system via SMIT or used the chfs command. Then perhaps we should have removed the original LV (fslv04, after confirming the copy was good) before exporting the VG. Let’s now get out of this mess. The following will fix it by correcting the LV association and removing fslv04:

# umount /holding
# chfs -a dev=/dev/x_fslv04 /holding
# rmlv fslv04
Warning, all data contained on logical volume fslv04 will be destroyed.
rmlv: Do you wish to continue? y(es) n(o)? y
rmlv: Logical volume fslv04 is removed
# lsvg -l hold_vg
hold_vg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1       1       1    open/syncd    N/A
x_fslv04            jfs2       64      64      1    open/syncd    /holding

There will still be a duplicate entry in /etc/filesystems, one for fslv04 and one for x_fslv04 associated with /holding. Unfortunately you don’t have a lot of choices and must still manually remove fslv04 entries for /holding. Don’t use SMIT as you may well remove the real /holding entry.

Be Warned

If you’re manually editing /etc/filesystems and you forget some time in the future and export the VG and re-import to the same or different host, be prepared for a surprise. Although it’s not a showstopper, you’ll still want to be forewarned of the trouble and how to fix it.