Alright.. here is what I got as an RCA for this issue:   Upon analysis, EMC has told that the SRDF state was in split state prior to the meta member of that particular R1 metahead got corrupted. As per EMC, due to longer split times and production data continously hitting one of the R1 meta member, the meta member got corrupted which resulted in this downtime. So to be on a safer side, I think its a best practise to split the R1-R2 only on purpose and once the change is done, change the mode but not keep the R1-R2 in split state for longer times.   Hope it helps.  Taz
Dear SAN Admins,  I had a weird "disk failure" issue yesterday which resulted in an outage in our production environment.  There was a thin meta with a inconsistent meta member which resulted in a database panic and the file system going offline on a AIX box. Also this thin meta was a part of SRDF/A replication. Until we knew the issue, EMC tech support dialed home and worked on the SRDF repair and got the file system back online and we resumed production. Later on we came to know there is a "possible" disk failure on our VMAX and a CE will be able to identify that.   symdisk list -failed does not show any failed disks.  Any possible causes ? (The frame is on latest code 5876).   Regards Taz
symdisk list does not show disk failure but emc says possible disk failure