Error Message

Thread in question. odm resize stuck in vx_sec_getdele - get delegation from another nodes ssuml001_415-102-501_tlist.out: vx_odm_resize+0x16c(3008c73a540, f2000, 19008, 0, 300702988a0, 8000)

Known Incident

After reviewing the threadlist with backline you have hit the following incident. E1206129) Changed vx_extprevfind to avoid whole AU allocations on a CFS secondary. Changed vx_cfs_smalltrunc to no longer try to guess about larger files. If a file can have a whole AU allocation, the file is now treated as a large truncation no matter how much space is being removed from the file. Even removing one block can break up a whole AU allocation. The incident is fixed in vxfs 5.0-MP1-RP4 onward. https://sort.Veritas.com/patch/detail/1077/0/cGF0Y2gvc2VhcmNobWF0cml4LzIxLzEvNA== MP3 has the fix as well. Our recommendation is to upgrading to MP3 + RP5.

3 nodes - Storage Foundation RAC 5.0 MP1 on Solaris 10 with EMC Symmetrix Storage presented to the cluster - No EMC Powerpath. All CFS related filesystems are hung and cannot be accessed. The applications/database Services have failed over to another datacenter on the replicated site (They use SRDF for replication so no VVR). ==>> What is type of a hang? Applications and Databases cannot access the data on the cfs filesystems. ls -l on cfs filesystems hangs df is also hanging cd is hanging But they are able to login to the server so it is not a server wide hang. vxvm commands are running ok Everything else is working ok except all SFCFS related filesystems are hung They want to know what is causing this hang. I explained that there are many cfs/cvm related hang issues since 5.0 MP1 which have been fixed but they want us to identify what exact issue are they hitting if it is a known issue. Requested to collect the system crashdumps from all the nodes at the same time in the specific sequence