<div dir="ltr"><div><br></div><div>If an object write is sent to a hand off location, is that object deleted from that hand off location once the primary write location is written to?  In my testing, I forced a new object write to hand off locations. Once I brought the primary locations back online, the object is then written to all primary locations however the object still resides in the handoff location. <br><br></div><div>Please advise.<br><br>Thanks!<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 12:41 PM, Brent Troge <span dir="ltr"><<a href="mailto:brenttroge2016@gmail.com" target="_blank">brenttroge2016@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks John.. I truly appreciate your clear and concise answers.<div><br></div><div><br><div><br></div><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 12:09 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well listings is slightly different than being able to read the data if you already know the object name.<br>
<br>
Assuming no failures in the system, the container listings will be up to date before the end-user gets a 2xx response. That is, create a new object, then immediately do a listing, and you'll see the object in that listing.<br>
<br>
However, we can pretty safely assume that there will be failures at some point (especially if it's a larger cluster). In that case, the end-user will still get a 2xx response because the data was durably flushed to disk, but the container listing update may fall back to an asynchronous update. In that case, you may or may not get the object in a container listing until container replication has completed. But you'll still be able to read the object directly if you know the name.<br>
<span><font color="#888888"><br>
--John<br>
</font></span><div><div><br>
<br>
On Sep 9, 2014, at 9:15 AM, Brent Troge <<a href="mailto:brenttroge2016@gmail.com" target="_blank">brenttroge2016@gmail.com</a>> wrote:<br>
<br>
> Thanks..  My understanding is that an object will not be listed within a container until it completes replication throughout the cluster. Thats what I meant by 'listing'<br>
><br>
> But you corrected that mis-understanding.  Such that, with respect to my 3 write requirement, an object will be available  in each region once I receive a 200 upon file ingest.<br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Sep 9, 2014 at 10:02 AM, John Dickinson <<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>> wrote:<br>
> I'm not sure what the question is.<br>
><br>
> If you are looking to have a successful response after it's written twice in a cluster with 4 replicas, no. Swift's quorum calculation is (replicas DIV 2 + 1). This means that for 4 replicas, you have a quorum size of 3. What I would suggest you look in to is the write_affinity setting so that you can do a full-quorum (at least) write to the local region and then asynchronously replicate to the other region. See <a href="http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters" target="_blank">http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters</a> and <a href="https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/" target="_blank">https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/</a>.<br>
><br>
> If you are looking to ensure that there is at least one replica in each region, then yes. The quorum size of three (see above) will ensure that, without any write_affinity settings, you'll have at least one replica in each region and two in another before the client gets a 2xx success response code to the PUT request.<br>
><br>
> --John<br>
><br>
><br>
><br>
> On Sep 9, 2014, at 6:59 AM, Brent Troge <<a href="mailto:brenttroge2016@gmail.com" target="_blank">brenttroge2016@gmail.com</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > If I configure Swift to use 4 replicas across two regions(two replicas per region), is it possible to only list a newly ingested object if it has written at least twice? The goal is to only list a new object only if it has a presence in each region.<br>
> ><br>
> > west coast<br>
> > region 1 - zone 1<br>
> > region 1 - zone 2<br>
> ><br>
> > east coast<br>
> > region 2  - zone 1( 3?)<br>
> > region 2 -  zone 2( 4?)<br>
> ><br>
> > Thanks!<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> > Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
> > Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>