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.
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
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.
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.
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.
Article Number: 32
Posted: Tue, May 22, 2018 2:25 PM
Last Updated: Tue, May 22, 2018 2:25 PM
Online URL: http://kb.ictbanking.net/article.php?id=32