vxfs fsck: OLT extent 0 has bad magic

[Marvin Strong]

#fsck -F vxfs -o full /dev/vg08/ftpresfs
vxfs fsck: OLT extent 0 has bad magic
read of primary OLT failed
vxfs fsck: OLT extent 1 has bad magic
read of OLT copy failed
vxfs fsck: no valid OLT, cannot continue
file system check failure, aborting ...

anyway other than a restore to fix this?

[Steven E. Protter]

I would suggest umounting the filesystem if its mnounted.

Try the script i'm attaching. $1 is the r device the filesystem is sitting on.

SEP

[Marvin Strong]

It is unmounted, I had already tried both the block and character device.

thanks

[Mark Ray_1]

Hello Marvin,

The error is usually an indication that the beginning of the filesystem has been overwritten or corrupted. When a file system is mounted, JFS reads the Superblock first, then reads the Object Location Table (OLT).

If a filesystem is corrupted while it is mounted, it can often go undetected since many key structures are already in memory. When the filesystem is unmounted, the Superblock is flushed to disk, but the OLT is not (since it has static information in it). This explains why the Superblock is OK but the OLT is bad.

You can use fsdb to examine the contents of
the OLT if you desire. Below is an example:

# fsdb -F vxfs /dev/vgXX/lvolyy
> 8192 B; p S | grep olt
oltext[0] 33 oltext[1] 1282 oltsize 1

Now use the oltext[] to display the OLT:

> 33 b; p oltext
OLT at 0x00000021.0000
OLT head entry:
olt_magic 0xa504fcf5 olt_size 56 ...

The magic number should always be 0xa504fcf5. Try on a good FS and compare the OLTs.

Newfs and restore the data is the best recovery method.

Best Regards,

Mark

[Marvin Strong]

As I suspected there would be no way to recover.

thanks for the additional info.

[Hazem Mahmoud_3]

We encountered the same problem a couple of weeks ago. It ended up being a corrupted file system. We had no choice but to wipe out the file system and recreate it. Luckily, it only held log information, and not data, so the impact was minimal.

-Hazem