3 ms·
Okay so I got to the wrap-up at the end, about "why did nobody else find this", the author sets up some logical dominoes but doesn't knock them down. Allow me t
by myself248 4y ago
Okay so I got to the wrap-up at the end, about "why did nobody else find this", the author sets up some logical dominoes but doesn't knock them down. Allow me to try:
Earlier in the article, the author mentions that they recently upgraded some network hardware, and the problem seemed to become more frequent after that.
Packet loss or other network issues would force the stack to fall out of fast-path and update the counter, avoiding the bug.
Running over ssh would avoid the bug. The only time you'd run rsync not over ssh would be within your own network.
So it sounds like (this is my conjecture here) this would only appear to someone running rsync internally, over a high-performance network with no packet loss, and upgrading the switches might've finally gotten the network good enough to expose the bug?
- ardel95 4y agoThat sounds plausible. But also, most software (browsers, web service SDKs, RPC frameworks) treat TCP connections as fallible by setting read/write timeouts and aggressively reopening broken connections. So, I’m totally not surprised this issue went unnoticed for this many years.
- cryptonector 4y agoOne might expect this to have been hit by HPN (high performance networking) users, but perhaps if they are storage I/O bound rather than CPU or network I/O bound, then probably not.