That's actually this post (the fallacies link). :-) And you make a good argument about handling read errors. In practice that's not what high availability is

That's actually this post (the fallacies link). :-) And you make a good argument about handling read errors. In practice that's not what high availability is about though, and it's certainly not what we're talking about with AWS, iSCSI or even an HA-NFS solution. Availability in those terms is properly designed, redundant infrastructure. There are many cases I'm sure (say a Stock-Exchange) where HA-NFS would not be appropriate. In your average web-app however, request failures while transitioning to failover are (in my experience) just part of the bargain. In that context, waiting 60 seconds for a stale NFS handle to pick a new connection up on the VRRPed failover node is acceptable, and like you said, you make assumptions and don't worry about the edge-case here. There are clearly situations where NFS wouldn't work well, but those are definitely the exception to the rule. There are not a lot of reasons/scenarios where iSCSI couldn't or shouldn't replace local storage for virtualization needs however. In my opinion. iSCSI is simple and extremely reliable. Perhaps even more reliable than local disks, especially if the primary concern is availability. Frankly, I don't know that these rules are really something that applies at the level of a polished iSCSI or NFS stack. They certainly apply to the internals of those systems. While you or I aren't going to worry about wether a buffered-file-reader can fetch the next 8K block, that thought and engineering effort definitely has been put into these protocols and implementations at a lower level than you or I will typically work with.