Problem
"vxdisk -g dg_name resize disk_name" failed then vxconfigd daemon died. No core dump left.
Error Message
[ ERROR MESSAGES ]
1. According to the technote: TECH140473, the error message is as follows.
# vxdisk -g testdg resize sda
VxVM vxdisk ERROR V-5-1-8643 Device sda: resize failed: Unsupported partition layout
2. However, sometimes there is no error messages left because vxconfigd died without core since VxVM5.0MP4(1797540: The vxdisk resize no longer intermittently causes vxconfigd to dump core)
Cause
Etrack: 2156649
TN: TECH140473
Solution
[ WHAT NEED TO CHECK AT OS LEVEL? ]
1. Confirm the disk actually can handle more than 2TB.
For Linux to do this, it will be required to need a GPT label on the disk. So, to check do the following:
#parted /dev/sdb
(parted) print
- After the output is seen, just type in quit to exit parted
- Then something should be seen like this:
(parted) print
Disk geometry for /dev/hda: 0.000-2445.679 megabytes
Disk label type : msdos
Minor Start End Type Filesystem Flags
1 0.031 945.000 primary fat32 boot, lba
2 945.000 2358.562 primary ext2
3 2358.562 2445.187 primary linux-swap
(parted) print 1
Minor: 1
Flags: boot, lba
File System: fat32
Size: 945.000Mb (0%)
Minimum size: 84.361Mb (0%)
Maximum size: 2445.679Mb (100%)
Note: Please note above that the label type is “
msdos ” (and
will NOT support) big disks
If there is a GPT label on the disk, all should be fine for the disk over 2TB.
If there is NOT a GPT label on the disk,
it is required to re-label the disk , which means that ALL data on the disk will be lost !!!
2. If there is no GPT label on the disk, it may be needed to look for what can be salvaged from the disk.
- See what the partitions are and search for the partition with the type “f” (indicating a private region).
- If it is missing (because the resize actually calls parted and gave the size invalid, parted failed and messed up the disk),
- Then redo the partitions from the CBR (if this is not the only disk in a DG, just doing an init again might help and then followed by a “adddisk –k” ).
- In inference, if only the partition table is stuffed on this disk and that once doing “fix” it is done, then the data will be accessible again.
3. So therefore, please CHECK if the resized LUNs are re-labeled or not after size increase.
[ WHAT TO DO AT VxVM LEVEL ? ]
----------------------------------------------------------------------------------------------
1. Please save the configuration data of disks.
#vxdisk list sdb
2. Place the disks offline with the command vxdisk offline <disk>
#vxdisk offline sdb
3. Use the command blockdev --rereadpt /dev/vx/dmp/<disk>
#lockdev --rereadpt /dev/vx/dmp/sdb
4. Place the disks online with vxdisk online <disk>
#vxdisk online sdb
5. Rescan the disk with vxdisk scandisk
#vxdisk scandisks
6. Check to see if the configuration data gets wrong due to some reason by comparing with the previous configuration data in the step #1.
# vxdisk list sdb
Now the disk will be shown as online and as normal.
----------------------------------------------------------------------------------------------
On the other hand, in case there is anything wrong even after step 6 above,
----------------------------------------------------------------------------------------------
1. please initialize the disk with the configuration data from the step above
#/usr/lib/vxvm/bin/vxdisksetup -i sdb format=sliced privoffset=16065 privlen=15808 puboffset=32130 publen=9367308720
2. Then try to add disk to disk group by force
#vxdg -g PDDG -k adddisk sdb
3. Thereafter, please start volume
#vxvol -g PDDG -f start PD-volume
4. Then mount the file system
# mount -t vxfs /dev/vx/dsk/datadg/datavol /data
Applies To
[ The version of OS/Package ]
- Linux symc-linux 2.6.16.60-0.66.1-smp #1 SMP Fri May 28 12:10:21 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
- VRTSvxvm-common-5.0.40.00-MP4_SLES10
VRTSvxvm-platform-5.0.40.00-MP4_SLES10
