- Super block showing the wrong magic and version numbers. It should show magic number "a501fcf5" and version number less than or equal to 17.
$ echo "8192B.p S" | fsdb -t vxfs /dev/vx/rdsk//
super-block at 00000008.0000
magic 42434f54 version 1262702412 variant 757465088
uuid 00000000-0000-0000-0000-000000000000
volguid 00000000-0000-0000-0000-000000000000
ctime 0 0 (Thu Jan 1 00:00:00 1970 UTC)
log_version 909588785 logstart 0 logend 0
bsize 2852126720 size 432556670460100608 dsize 432556670460100608 ninode 0 nau 0
defiextsize 0 oilbsize 0 immedlen 96 ndaddr 10
aufirst 0 emap 0 imap 0 iextop 0 istart 0
bstart 0 femap 0 fimap 0 fiextop 0 fistart 0 fbstart 0
nindir 2048 aulen 32768 auimlen 0 auemlen 0
- From the CBR Backups and during resize operation, we have observed disk_offset is 48 but private offset is 256, Here 208 is expected as the disk had been resized and changed to gpt format. Later at some point, the private offset changed to 208 .
$ egrep "Device:|private:|public:" vxdisk_list_emc0_02ea
Device: emc0_02ea
public: slice=3 offset=65744 len=2306802640 disk_offset=48
private: slice=3 offset=256 len=65536 disk_offset=48
For a single path disk, during two transactions of resize operation, the private region IOs could be incorrectly sent to partition 3 of the GPT disk, which would cause a 48 sector shift. This may make the private region data over-write the first 48 sectors of the public region and cause corruption.
For Multipath disks, the problem is still under investigation.
All Infoscale versions are affected. However, the issue has only been seen in version 7.4.2 on Linux platform.
This table will be updated as further fixes become available.
|
Version |
Linux |
Solaris |
AIX |
|
7.4.2 |
7.4.2u6 |
7.4.2.3702 (contact support) |
Contact support |
Install the patch prior to doing any disk resize.
Disk Resize from lower than 1TB to 1TB or above followed by reimport/reboot corrupts the file systems. The issue is particularly observed when using SRDF luns.
JIRA: STESC-7855 ETrack: 4112687