Open Stack

Thanks for the detailed explanation...

>>
>>
>> 1. So when the replicator catches up, it will move the object back to
>> the correct location. Is that right?
>
>
> The read path will find the object on any primary or any handoff location.
> The replicator *will* copy the data files to the primary and delete it from
> the handoff once it's successfully in sync.  But GETs for the object will be
> able to find the object during that entire process.  Having data written to
> a handoff location does not mean it is unaccessible - quite the opposite -
> stable handoff ordering is the mechanism that enables data to be accessible
> during failure of primary storage devices.

This is unlike what I've seen in this setup. I have some code that
tried to read the object 5 times from Swift with exponential backoff.
But it failed with a 404 on all occassions which is why it gave up. I
also tried manually using swift command line tool and got back an
object "not found" error.
The object was found in the *second* handoff node. Not the first. Does
that matter.

The replicator eventually did transfer the blob to the original node.
After that things were just fine...