Filesystem check fsck fails with OLT extents conflict with Errors: V-3-20718, V-3-20726 and V-3-20729

book

Article ID: 100020562

calendar_today

Updated On:

Description

Error Message

# fsck -F vxfs -o full /dev/vx/rdsk/testdg/testvol
UX:vxfs fsck: ERROR: V-3-20729: OLT extents conflict
read of primary OLT failed
UX:vxfs fsck: ERROR: V-3-20726: OLT extent 1 has bad checksum
read of OLT copy failed
UX:vxfs fsck: ERROR: V-3-20718: no valid OLT, cannot continue
file system check failure, aborting ...

Cause

The superblock on the filesystem has been incorrectly flushed with  wrong superblock belonging to an alternative filesystem

 

Resolution

Determine why fsck is reporting OLT conflict using  using fsdb:

1. Check the location of the OLT from the superblock  and the content at 2 locations using fsdb utility

# fsdb -F vxfs  /dev/vx/rdsk/testdg/testvol
> 8192B.p S | grep olt
oltext[0] 32 oltext[1] 3330 oltsize 1                                        <<<<   2 OLT locations in blocks

> 32b.p oltext
OLT at 0x00000020.0000
OLT head entry:
       olt_magic 0xa504fcf5 olt_size 64 olt_totfree 776
       olt_time 1156509534 503 (Fri Aug 25 05:38:54 2006 PDT)
       olt_checksum 0x44eeff9a 
       olt_esize 1 olt_extents[32 3330]                                      
       olt_nsize 0 olt_next[0 0]
..

> 3330b.p oltext 
OLT at 0x00000d02.0000
unsupported OLT entry
type 0x4e4c3474 offset 0x0 size 1969103425
Bad magic number in OLT header entry
OLT head entry:
olt_magic 0x4e4c3474 olt_size 1969103425 olt_totfree 1416903757
olt_time 1815491388 1193893409 (Tue Jul 13 08:09:48 2027 PDT)
olt_checksum 0x4a3e6147 (bad checksum; should be 0xcfcff54b)
olt_esize 1530688841 olt_extents[7079503940732930930 7581652091025763628]
olt_nsize 1515546708 olt_next[5496151208029856781 720670498382238514]
.. 

Note:  Primary OLT at location block 32 looks OK so why the OLT conflict 

2. Check voume and filesystem details, to confirm if the superblock is valid

# vxprint -g testdg -htq testvol
v testvol - ENABLED ACTIVE 257949696 SELECT - fsgen
pl testvol-01 testvol ENABLED ACTIVE 257949696 CONCAT - RW
sd d4-01 testvol-01 d4 0 257949696 0 c3t50060E80004372C0d23 ENA    <<<  disk which has the metadata (superblock copies)

# echo  "8b.p S" |fsdb -F vxfs /dev/vx/rdsk/testdg/testvol | grep ^bsize
bsize 1024 size 15728640 dsize 15728640 ninode 0 nau 0

The filesystem size is 15728640Kbytes (15G) with a default block size, bsize=1024bytes, while volume size is 257949696sectors (128G). 
Note: The main superblock is NOT the correct one for this filesystem.
 

3. Locate an alternative superblock on the filesystem using the Magic Number = a501fcf5 

#  dd if=/dev/rdsk/c3t50060E80004372C0d23 bs=1024k | od -Ax -X | grep a501fcf5
0002000 a501fcf5 00000006 00000400 00000004     <<<  1st   Superblock (default location 8b)  is not correct
00c0c00 a501fcf5 00000006 00000400 00000004     <<<   2nd Superblock (alternative location 771b) might be correct 

File system size is matching with volume size.(120G)

# echo "0x00c0c00" | fsdb -F vxfs /dev/vx/rdsk/testdg/testvol | grep ^bsize 
bsize 1024 size 128974848 dsize 128974848 ninode 0 nau 0

4. Checking the OLT extents are also correct.

# echo "0x00c0c00 B.p S" | fsdb -F vxfs /dev/vx/rdsk/testdg/testvol | grep olt
oltext[0] 32 oltext[1] 770 oltsize 1                                      <<<   2nd OLT = oltext[1] at 770b is different from earlier

# echo "770b.p oltext" | fsdb -F vxfs /dev/vx/rdsk/testdg/testvol 
OLT at 0x00000302.0000
OLT head entry:
olt_magic 0xa504fcf5 olt_size 64 olt_totfree 776
olt_time 1156509534 503 (Fri Aug 25 05:38:54 2006 PDT)
olt_checksum 0x44eeff9a
olt_esize 1 olt_extents[32 770]
olt_nsize 0 olt_next[0 0]
..
This olt looks good as part of the alternative superblock, so we now have a valid alternative superblock with matching OLT extents. So  the default superblock at location 8p (=8192B)  was corrupted  and probably overwritten from another filesystem.  We recommend to rebuild the filesystem (mkfs)  and restore from backup since we cannot be 100% sure what has been overwritten.

Alternatively if wish to proceed (no backup available) to make a "best effort" to recover as much data as possible the process the following workaround can be implemented.

(NEED TO CONFIRM THE ACTUAL OFFSET OF THE ALT SB)

1. Create a backup copy of the alternative good superblock and check
# dd if=/dev/vx/rdsk/testdg/testvol bs=1024  skip=770 count=1 of=sb1                                        

# fsdb -F vxfs sb1
fsdb: cannot read super-block
fsdb: bad super-block or metadata - setting block size to 1024
- setting ino per extent to 32

> 0b.p S
super-block at 00000000.0000
magic a501fcf5 version 6
...
oltext[0] 32 oltext[1] 770 oltsize 1

2. Overwrite the master superblock using the backup superblock copy and check
# dd if=sb1 of=/dev/vx/rdsk/testdg/testvol bs=1024 seek=8 count=1 conv=notrunc           

# fsdb -t vxfs /dev/vx/rdsk/testdg/testvol
> 8192B.p S
super-block at 00000008.0000
magic a501fcf5 version 6
...
oltext[0] 32 oltext[1] 770 oltsize 1

3. Run full fsck and mount the filesystem

# fsck -F vxfs -o full /dev/vx/rdsk/testdg/testvol

# mount -F vxfs /dev/vx/rdsk/testdg/testvol /tmnt
 

 

 

Issue/Introduction

Possible issue with DMP path or duplicate virtual device number.