This is because vxrecover does the RVG recovery. When vxrecover is triggered after storage failure it is possible that the vxrecover operation may hang. In a Veritas Volume Manager(VVR) environment vxrecover command can hang. If the same operation is carried out on 2 servers having shared storage then zpools would be imported on top of DMP devices on both the servers approximately at the same time which leads to zpool corruption.Ĭhanges have been done to not import exported zpools on top of DMP devices and let the customer decide which zpools to import on which server. During migration even exported zpools are imported on top of DMP devices. When DMP Native Support is enabled then all the zpools present on the system are migrated to DMP devices. Zpool corruption occurs when DMP Native Support is enabled on two servers at the same time. The issue occurs because the memory allocated to store these values are not reset to 0 for different disks leading to garbage/incorrect values being displayed as part of the command output.Īppropriate changes have been incorporated to reset the memory to 0 while calculating stats for each of the disks. Similar thing would happen for disk2/disk3 and so on. The IO operations for disk 1 would be added to disk 2 and then displayed. Vxstat command shows accumulated data for IO Operations for underlying disks. Vxstat command shows incorrect data for IO Operations. This leads to error during installation which can be only resolved post reboot.Ĭhanges have been done to verify if the modules present in the current patch are newer and accordingly remove the stale entry of older modules from Operating System. Because of this older entry the load of newer modules to support Solaris 11.4 which are part of the patch cannot succeed. The base release does not have support for Solaris 11.4 and hence as part of installing base release an entry for older modules is registered with Operating system. vxvm-configured file is present.Īppropriate modules are not loaded on the system during fresh installation of InfoScale on Solaris 11.4 systemĭuring fresh installation of InfoScale Enterprise software on Solaris 11.4 system both the base release as well as the patch are installed with one command. But since the check for the file is there, copying of the library is skipped on boot.Ĭhanges have been done to verify the cksum of the library and then decide where new module replacing is required or not even if the. If the OS of the system is upgraded from 11.3 to 11.4 then on reboot newer library should be copied pertaining to Solaris 11.4. The script runs only once and then it skips because of the. In Solaris 11 the work of postinstall script is done by vxvm-configure script. In Solaris 11.4 the concept of dual VRTS_vxvm_link.so library support for Solaris was included. If the OS of the system is upgraded from 11.3 to 11.4 then on reboot newer library were not copied pertaining to Solaris 11.4. This patch fixes the following incidents: * 4010520 (4003805) Panic encountered when using Oracle with mirrored volumes and DCOs on IS 7.4.1/Sol11.4 * 4010517 (3998475) Unmapped PHYS read I/O split across stripes gives incorrect data leading to data corruption. * 4008748 (3989185) In a Veritas Volume Manager(VVR) environment vxrecover command can hang. * 4006949 (4006539) zpool corruption occurs when DMP(Dynamic Multipathing) Native Support is enabled on two servers at the same time. * 4005540 (3970627) vxstat command shows incorrect data for IO Operations. * 3984165 (3982817) Appropriate modules are not loaded on the system during fresh installation of InfoScale on Solaris 11.4 system * 3968739 (3968334) Solaris 11.4: Appropriate library VRTS_vxvm_link.so is not copied on the system after OS upgrade. * DETAILS OF INCIDENTS FIXED BY THE PATCH * SUMMARY OF INCIDENTS FIXED BY THE PATCH * OPERATING SYSTEMS SUPPORTED BY THE PATCH This document provides the following information:
0 Comments
Leave a Reply. |