ITEM: BT4134L

importing filesystems at 4.1 fails on 4.2-specific filesystems

Question:

Env: 4.2.0 and 4.1.4 on two different machines.

Desc:  The customer created a volume group on a 4.2 machine with
filesystems that had sizes and nbpi and frag parameters that are
in accordance with AIX 4.1.  When the volume group is imported on
an AIX 4.1.4 machine, no stanzas are created for these filesystems
in /etc/filesystems.  There are absolutely no errors from the
importvg command, and no other logical volume with a conflicting
name or filesystem entry with the same mount point.

Action:  We checked the Logical Volume Control Block (LVCB) with
"getlvcb -AT LVname"; it had complete entries, including a type,
label, and fs entries, from which the /etc/filesystems stanza
would be built.

We ran "imfs VGname" and "imfs -l LVname" (the latter on each
logical volume).  This returned no errors but still didn't create
an entry.  We directly placed a stanza in /etc/filesystems and
ran "chfs /mountpoint" to update the LVCB on one logical volume,
but exportvg/importvg resulted in no stanza.

The following commands indicate a problem:

\# imfs -D testvg
...
read_cmd: "/usr/sbin/getlvcb -L fslv03"
importlv("fslv03"): mountpoint is /home/apps/d05/oracle
        skipped - not a jfs
...

\# fsck -o nologredo /dev/fslv03
Filesystem Helper: 0506-506 Invalid argument

\# fsck -V jfs -o nologredo /dev/fslv00
%_OS_% filesystem, Incompatible version number. (TERMINATED)

\# dumpfs /dev/fslv00
dumpfs:  506-011  /dev/fslv00 is not a supported JFS filesystem version.

We looked at the superblocks with "lquerypv -h /dev/[LV] 1000 100"
and found that the magic number, at offset 0x1000 was indeed a
version 4.1 magic number (65872143).

\# lquerypv -h /dev/fslv03 1000 100
00001000   65872143 00000000 00004000 00000001  |e.!C......@.....|
00001010   00174000 10000000 2F686F6D 652F0000  |..@...../home/..|
00001020   00000000 00240002 00000000 32925CAA  |.....$......2.\\.|
00001030   00000002 00001000 00004000 00000000  |..........@.....|
00001040   00000005 00000000 00000000 00000000  |................|
00001050   00000000 00000000 00000000 00000000  |................|
00001060   00000000 00000000 00000000 00000000  |................|
00001070   00000000 00000000 00000000 00000000  |................|
00001080   00000000 00000000 00000000 00000000  |................|
00001090   00000000 00000000 00000000 00000000  |................|
000010A0   00000000 00000000 00000000 00000000  |................|
000010B0   00000000 00000000 00000000 00000000  |................|
000010C0   00000000 00000000 00000000 00000000  |................|
000010D0   00000000 00000000 00000000 00000000  |................|
000010E0   00000000 00000000 00000000 00000000  |................|
000010F0   00000000 00000000 00000000 00000000  |................|

The magic number looks OK, but further analysis of
/usr/include/jfs/filsys.h shows that the VERSION number (the 2 at
offset 0x1030) may be what is holding us back.  I went to a 4.2 machine
and created a jfs filesystem with ag=16 and nbpi=32K, and it created a
filesystem with identical magic and version numbers.

Note the difference in version number with a working filesystem.  

\# lquerypv -h /dev/fslv02 1000 100
00001000   43218765 00000000 00000800 00000002  |C!.e............|
00001010   0022C000 10000000 2F686F6D 652F0000  |."....../home/..|
00001020   00000000 00200002 00000000 32925C9C  |..... ......2.\\.|
00001030   00000000 00000000 00000000 00000000  |................|
00001040   00000000 00000000 00000000 00000000  |................|
00001050   00000000 00000000 00000000 00000000  |................|
00001060   00000000 00000000 00000000 00000000  |................|
00001070   00000000 00000000 00000000 00000000  |................|
00001080   00000000 00000000 00000000 00000000  |................|
00001090   00000000 00000000 00000000 00000000  |................|
000010A0   00000000 00000000 00000000 00000000  |................|
000010B0   00000000 00000000 00000000 00000000  |................|
000010C0   00000000 00000000 00000000 00000000  |................|
000010D0   00000000 00000000 00000000 00000000  |................|
000010E0   00000000 00000000 00000000 00000000  |................|
000010F0   00000000 00000000 00000000 00000000  |................|

The customer took this volume group back to the 4.2 machine, 
imported it, and ran "lsfs -q".  This indicates that the
filesystems were created with bf=true and ag=64, meaning that
they are Large File-Enabled filesystems with an allocation group
size of 64.  This means that they are 4.2-specific filesystems,
EVEN though their magic number corresponds to a AIX 4.1-type
filesystem, due to its size.

AIX 4.2-specific filesystems will not successfully import on
AIX 4.1 machines.

Next:  Close.



Support Line: importing filesystems at 4.1 fails on 4.2-specific filesystems ITEM: BT4134L

Dated: January 1997 Category: N/A

This HTML file was generated 99/06/24~13:30:20

Comments or suggestions?
Contact us