I'll try to dig out the stacktrace, but the code in question was checking the encryption zone of both source and dest to determine if a rename is possible or must fallback to copy. This explained why I started seeing spikes of getEZForPath calls when we don't even use encryption zones!
IMHO, rename should throw an IOE-derived IncompatibleEncryptionZonesException instead a bland IOE. This would allow a client to blindly attempt the rename, catch the specific exception, fallback to copy if required. In the vast majority of cases that removes 2 junk calls for non-existence EZs.
In the name of compatibility, I lean towards reverting the incompatible change. This is one of the reasons 2.8 certification has ground to a halt. One could argue that most calls throw FNF because they query or manipulate a specific path. If it's not there, game over. But in the case of encryption zones and erasure coding, these features are tree-based. Properties are inherited by searching up the ancestor paths so it's more about asking "what is or would the EC or EZ be for this path?".
In any case, it now requires 3X rpcs to do a simple rename. I want specific exceptions to eliminate the 2 junk calls. The trend of new "always on" features... with direct or indirect non-trivial performance costs... for common operations... when not used... is becoming rather irritating. I'm email@example.com and I approve this