Don’t edit the /etc/filesystems file manually when creating file systems.

 

When you import a volume group, the importvg command will populate the /etc/filesystems file based on the logical volume minor number order (which is stored in the VGDA on the physical volume/hdisk). If someone manually edits the /etc/filesystems, then its contents will no longer match the order contained in the VGDA of the physical volume. This can become a problem the next time someone attempts to export and import a volume group. Essentially they may end up with file systems over-mounted and what appears to be the loss of data!

 

Here’s a quick example of the problem.

 

Let’s create a couple of new file systems; /fs1 and /fs1/fs2. I’ll deliberately create them in the “wrong” order.

 

# mklv -tjfs2 -y lv2 cgvg 1

lv2

 

# crfs -vjfs2 -dlv2 -Ayes -u fs -m /fs1/fs2

File system created successfully.

65328 kilobytes total disk space.

New File System size is 131072

# mklv -tjfs2 -y lv1 cgvg 1

lv1

 

# crfs -vjfs2 -dlv1 -Ayes -u fs -m /fs1

File system created successfully.

65328 kilobytes total disk space.

New File System size is 131072

 

Hmmm, lv2 appears before lv1 in the output from lsvg. The first indication of a potential problem!

 

# lsvg -l cgvg

cgvg:

LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT

lv2                 jfs2       1       1       1    closed/syncd  /fs1/fs2

loglv00             jfs2log    1       1       1    closed/syncd  N/A

lv1                 jfs2       1       1       1    closed/syncd  /fs1

 

Whoops! /fs1 should be mounted before /fs1/fs2!!! Doh!

 

# mount -t fs

 

# mount | tail -2

         /dev/lv2         /fs1/fs2         jfs2   Jul 19 23:07 rw,log=/dev/loglv00

         /dev/lv1         /fs1             jfs2   Jul 19 23:07 rw,log=/dev/loglv00

 

Data in /fs1/fs2 is now hidden and inaccessible. The /fs1 file system has over-mounted the /fs1/fs2 file system. This could look like data loss i.e. someone removed all the files from the file system.

 

# df -g | grep fs

/dev/lv2              -         -    -         -     -  /fs1/fs2

/dev/lv1           0.06      0.06    1%        4     1% /fs1

 

The file systems are listed in the wrong order in /etc/filesystems as well. Double Doh!

 

# tail -15 /etc/filesystems

/fs1/fs2:

        dev             = /dev/lv2

        vfs             = jfs2

        log             = /dev/loglv00

        mount           = true

        type            = fs

        account         = false

 

/fs1:

        dev             = /dev/lv1

        vfs             = jfs2

        log             = /dev/loglv00

        mount           = true

        type            = fs

        account         = false

 

No problem. I’ll just edit the /etc/filesystems file and rearrange the order. Simple, right?

 

# vi /etc/filesystems

 

/fs1:

        dev             = /dev/lv1

        vfs             = jfs2

        log             = /dev/loglv00

        mount           = true

        type            = fs

        account         = false

 

/fs1/fs2:

        dev             = /dev/lv2

        vfs             = jfs2

        log             = /dev/loglv00

        mount           = true

        type            = fs

        account         = false

 

Let’s remount the file systems in the correct order.

 

# umount -t fs

# mount -t fs

# df -g | grep fs

/dev/lv1           0.06      0.06    1%        5     1% /fs1

/dev/lv2           0.06      0.06    1%        4     1% /fs1/fs2

 

That looks better now, doesn’t it!? I’m happy now.....although, lsvg still indicates there could be a potential problem here…

 

# lsvg -l cgvg

cgvg:

LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT

lv2                 jfs2       1       1       1    open/syncd  /fs1/fs2

loglv00             jfs2log    1       1       1    open/syncd  N/A

lv1                 jfs2       1       1       1    open/syncd  /fs1

 

All is well, until one day someone exports the VG and re-imports it, like so:

 

# varyoffvg cgvg

# exportvg cgvg

 

# importvg -y cgvg hdisk2

cgvg

 

# mount -t fs

# mount | tail -2

         /dev/lv2         /fs1/fs2         jfs2   Jul 19 23:07 rw,log=/dev/loglv00

         /dev/lv1         /fs1             jfs2   Jul 19 23:07 rw,log=/dev/loglv00

 

Huh? What’s happened here!?  I thought I fixed this before!?

 

Try to avoid this situation before it becomes a problem (for you or someone else!) in the future. If you discover this issue whilst creating your new file systems, remove the file systems and recreate them in the correct order. Obviously, try to do this before you place any data in the file systems. Otherwise you may need to back up and restore the data!

 

# mklv -tjfs2 -y lv1 cgvg 1

lv1

 

# crfs -vjfs2 –dlv1 -Ayes -u fs -m /fs1

File system created successfully.

65328 kilobytes total disk space.

New File System size is 131072

# mklv -tjfs2 -y lv2 cgvg 1

lv2

 

# crfs -vjfs2 –dlv2 -Ayes -u fs -m /fs1/fs2

File system created successfully.

65328 kilobytes total disk space.

New File System size is 131072

 

You may be able to detect this problem, prior to importing a volume group, by using the lqueryvg command. Looking at the output in the “Logical” section, you might be able to ascertain a potential LV and FS mount order issue.

 

# lqueryvg -Atp hdisk2 | grep lv

0516-320 lqueryvg: Physical volume hdisk2 is not assigned to

        a volume group.

Logical:        00f603cd00004c000000013ff2fc1388.1   lv2 1

                00f603cd00004c000000013ff2fc1388.2   loglv00 1

                00f603cd00004c000000013ff2fc1388.3   lv1 1

 

Once you’ve identified the problem you can fix the issue retrospectively (once the VG is imported) by editing /etc/filesystems. Of course, this is just a temporary fix until someone exports and imports the VG again, in which case the mount order issue will occur again.

 

The essential message here is do NOT edit the /etc/filesystems file by hand when creating file systems.