This is similar to waitForSegmentsToShowUp which is called during Close/Commit. Intuitively, you wouldn't expect missing segments to be a problem during read operations, since the previous Close/Commit confirmed that all segments are there. But due to the distributed nature of Swift, the read request could be hitting a different storage node of the Swift cluster, where the segments are still missing. Load tests on my team's staging Swift cluster have shown this to occur about once every 100-200 layer uploads when the Swift proxies are under high load. The retry logic, borrowed from waitForSegmentsToShowUp, fixes this temporary inconsistency. Signed-off-by: Stefan Majewsky <stefan.majewsky@sap.com> |
||
|---|---|---|
| .. | ||
| azure | ||
| base | ||
| factory | ||
| filesystem | ||
| gcs | ||
| inmemory | ||
| middleware | ||
| oss | ||
| s3-aws | ||
| s3-goamz | ||
| swift | ||
| testdriver | ||
| testsuites | ||
| fileinfo.go | ||
| storagedriver.go | ||