Okay, sounds good.
I may sound paranoid but I have seen plenty of heartache about failing disks, bad h/w, or bad memory corrupting data.
If possible, open an SR and describe that your panic matches 15850819 and you would like a fix for it.
You are not paranoid. It's unclear to me how SA_MAGIC can become corrupt in the first place.
My working theory is that a bad byte in memory or a failing controller wrote the wrong header to disk in a redundant fashion. The data block then ends up looking consistent in checksum/redundancy, but is an invalid ZFS block and causes the kernel panic when it is read out during a file access.
I don't think my Oracle contract covers the piece of hardware in question and therefore I can not submit an SR. I don't even see bug #15850819 to tell you my opinion of whether it matches.
I'm going to turn NFS back on tomorrow to see if the resilvering/scrubbing managed to fix the bad block after all. And, in the meantime, ensure full backups of everything I can successfully read if I have to rebuild the zpool.
CR 15850819 is private and so its content isn't visible from customer MOS portal at least at the moment .
But it couldn't stop you from rising an SR against CR 15850819 and obtaining the fix.
Feel free to submit SR 'cause root cause is software problem, not hardware.
Could you translate the Oracle jargon (CR,SR,MOS, etc) into a concrete set of steps that I should take? I am not long experienced with Solaris/Oracle.
I can login to "My Oracle Support" just fine. Thanks for responding to this old thread!