Error Message

The VxFS metadata "fileset 1 primary-ilist inode 40 (DEV 1)" refers to the Device File (IFDEV) "Inode" listed in the Object Location Table (OLT) of a filesystem.   A VxFS Device refers to a volume in a Veritas Volume Manager (VxVM) Volume Set.    If the VxFS filesystem is created on a simple volume (where Volume Set is not used), then the will only be one VxFS Device (Device 0).  There are two copies of the VxFS Device file (DEV 0 and DEV 1).   "DEV 1" is the VxFS metadata inode pointing to the second copy of the VxFS Device.

The following is OLT display using the VxFS filesystem debugger (fsdb).

> olt
OLT at 0x00000020.0000
OLT head entry:
    olt_magic 0xa504fcf5  olt_size 64  olt_totfree 776
...........
 OLT device entry:   
    olt_type 5  olt_size 24  olt_devino[8 40]            <<< inode 8 is DEV 0 and inode 40 isDEV 1
..........
 

The following are the two metadata inodes displayed using VxFS fsdb. 

> 1fset.8i
inode structure at 0x00000012.0000
type IFDEV mode 2700000777  nlink 1  uid 0  gid 0  size 524288              <<< olt_devinfo[8[  and referred as "DEV 0" in fsck output
atime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
mtime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
ctime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
aflags 0 orgtype 1 eopflags 0 eopdata 0
fixextsize/fsindex 0  rdev/reserve/dotdot/matchino 40
blocks 512  gen 20548  version 0 0   iattrino 0
dotdot 0  inattrino 0
de:   40   0   0   0   0   0   0   0   0   0
des: 512   0   0   0   0   0   0   0   0   0
ie:    0   0
ies:   0

> 1fset.40i
inode structure at 0x0000090a.0000
type IFDEV mode 2700000777  nlink 1  uid 0  gid 0  size 524288            <<< olt_devinfo[40[  and referred as "DEV 1" in fsck output
atime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
mtime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
ctime 1345071270 494708  (Thu Aug 16 08:54:30 2012 EST)
aflags 0 orgtype 1 eopflags 0 eopdata 0                              <<< orgtype 1 - Organization Type1
fixextsize/fsindex 0  rdev/reserve/dotdot/matchino 8
blocks 512  gen 5452  version 0 0   iattrino 0
dotdot 0  inattrino 0
de:  2328    0    0    0    0    0    0    0    0    0       <<< Direct Extent offset
des:  512    0    0    0    0    0    0    0    0    0       <<< Direct Extent size
ie:     0    0
ies:    0

Please note that the following message doesn’t necessarily indicate that the corruption happened on the listed DEV inode.  VxFS fsck compares the data extents of inode 8 and inode 40, if their contents are different, then it will complain about DEV 1 regardless.

UX:vxfs fsck: ERROR: V-3-25503: invalid device config entry found in ino 40 offset 0
pass0 - checking structural files
fileset 1 primary-ilist inode 40 (DEV 1)
        failed validation clear? (ynq)n

We can compare the extent contents of the above two inodes by using "dd" and "od" commands.

Firstly, we need to find out the filesystem block size from the superblock.

# echo "8192B.p S" | fsdb -F vxfs /dev/vx/rdsk/"dg"/"volume"

For example, the following filesystem has 1KB block size.

# echo "8192B.p S" | fsdb -F vxfs /dev/vx/rdsk/"dg"/"volume"
super-block at 00000008.0000
magic a501fcf5  version 7
ctime 1331305445 943220  (Fri Mar  9 09:04:05 2012 CDT)
log_version 12 logstart 0  logend 0
bsize  1024 size  10485760 dsize  10485760  ninode 0  nau 0      <<< bsize 1024 (1KB)
....

Secondly, we obtain the hex dump from the inode extents.

# dd if=/dev/vx/rdsk/"dg"/"volume" bs="FS Block Size" skip="Direct Extent Offset" count="Direct Extent Size" | od -Ax -X > /var/tmp/DEVn.extents.od

Take the above filesystem as an example, we can dump the extents from DEV0 and DEV1 in hex format.

For DEV0 (1fset.8i), we have "de" of 40 and "des" of 512.

# dd if=/dev/vx/rdsk/"dg"/"volume" bs=1024 skip=40 count=512 | od -Ax -X > /var/tmp/DEV0.extents.od

For DEV0 (1fset.40i) we have "de" of 2328 and "des" of 512.

# dd if=/dev/vx/rdsk/"dg"/"volume" bs=1024 skip=2328 count=512 | od -Ax -X > /var/tmp/DEV1.extents.od

Finally we can compare the hex dumps and see if they are the same.

# diff   DEV0.extents.od   DEV1.extents.od

If there are any difference in the above two hex dump files, then fsck will complain about DEV 1 regardless of where the corruption appears.   It can either be corruption in DEV0 extents or DEV1 extents.   Please take a look at the two hex dumps and find out the corruption.    The unused VxFS Device records should contains all zeros.
 

Since there are two copies of the VxFS Device files, a full fsck should be able to recover the filesystem by getting the correct data from the redundant copy.    If you are in doubt, you can collect metasave of the filesystem and run full fsck on the restored vxfs image and assess the level of corruption.

The following is a sample fsck output which shows that the filesystem was recovered without any data loss.

# fsck -F vxfs -o full vxfsimage.fscked          
log replay in progress
pass0 - checking structural files
fileset 1 primary-ilist inode 40 (DEV 1)
        failed validation clear? (ynq)y                 <<<  Device File 1 (DEV 1) is removed
pass1 - checking inode sanity and blocks
rebuild structural files? (ynq)y                <<< Device File 1 (DEV 1) is rebuilt
pass0 - checking structural files        <<< There should not be any other filesystem corruption. If there are any other corruption reported, please don't proceed with the full fsck and contact Veritas Technical Support
pass1 - checking inode sanity and blocks 
pass2 - checking directory linkage
pass3 - checking reference counts
pass4 - checking resource maps            <<< Fixing the resource maps should be okay, the user data is not affected.
au 0 emap incorrect - fix? (ynq)y
au 0 summary incorrect - fix? (ynq)y
free block count incorrect 10465697 expected 10465688 fix? (ynq)y
free extent vector incorrect fix? (ynq)y
OK to clear log? (ynq)y
flush fileset headers? (ynq)y
set state to CLEAN? (ynq)y
 

Applies To

Veritas File System (VxFS) on all platforms