In this case, I believe that the GET will succeed.<br><br><div class="gmail_quote">On Fri, Jan 20, 2012 at 11:58 AM, Nikolaus Rath <span dir="ltr"><<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Sorry for being so persistent, but I'm still not sure what happens if<br>
the 2 servers that carry the new replica are down, but the 1 server that<br>
has the old replica is up. Will GET fail or return the old replica?<br>
<br>
Best,<br>
Niko<br>
<br>
On 01/20/2012 02:52 PM, Stephen Broeker wrote:<br>
> By default there are 3 replicas.<br>
> A PUT Object will return after 2 replicas are done.<br>
> So if all nodes are up then there are at least 2 replicas.<br>
> If all replica nodes are down, then the GET Object will fail.<br>
><br>
> On Fri, Jan 20, 2012 at 11:21 AM, Nikolaus Rath <<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a><br>
> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> So if an object update has not yet been replicated on all nodes, and all<br>
> nodes that have been updated are offline, what will happen? Will swift<br>
> recognize this and give me an error, or will it silently return the<br>
> older version?<br>
><br>
> Thanks,<br>
> Nikolaus<br>
><br>
><br>
> On 01/20/2012 02:14 PM, Stephen Broeker wrote:<br>
> > If a node is down, then it is ignored.<br>
> > That is the whole point about 3 replicas.<br>
> ><br>
> > On Fri, Jan 20, 2012 at 10:43 AM, Nikolaus Rath <<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a><br>
> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>><br>
> > <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > What happens if one of the nodes is down? Especially if that<br>
> node holds<br>
> > the newest copy?<br>
> ><br>
> > Thanks,<br>
> > Nikolaus<br>
> ><br>
> > On 01/20/2012 12:33 PM, Stephen Broeker wrote:<br>
> > > The X-Newest header can be used by a GET Operation to ensure<br>
> that<br>
> > all of the<br>
> > > Storage Nodes (3 by default) are queried for the latest copy of<br>
> > the Object.<br>
> > > The COPY Object operation already has this functionality.<br>
> > ><br>
> > > On Fri, Jan 20, 2012 at 9:12 AM, Nikolaus Rath<br>
> <<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>><br>
> > <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>><br>
> > > <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>><br>
> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>>>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > No one able to further clarify this?<br>
> > ><br>
> > > Does swift offer there read-after-create consistence like<br>
> > > non-us-standard S3? What are the precise syntax and<br>
> semantics of<br>
> > > X-Newest header?<br>
> > ><br>
> > > Best,<br>
> > > Nikolaus<br>
> > ><br>
> > ><br>
> > > On 01/18/2012 10:15 AM, Nikolaus Rath wrote:<br>
> > > > Michael Barton <<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a><br>
> <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a>><br>
> > <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a><br>
> <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a>>><br>
> > > <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a><br>
> <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a>><br>
> > <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a><br>
> <mailto:<a href="mailto:mike-launchpad@weirdlooking.com">mike-launchpad@weirdlooking.com</a>>>>> writes:<br>
> > > >> On Tue, Jan 17, 2012 at 4:55 PM, Nikolaus Rath<br>
> > <<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>><br>
> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>><br>
> > > <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>><br>
> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a> <mailto:<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>>>>> wrote:<br>
> > > >>> Amazon S3 and Google Storage make very explicit (non-)<br>
> > consistency<br>
> > > >>> guarantees for stored objects. I'm looking for a similar<br>
> > > documentation<br>
> > > >>> about OpenStack's Swift, but haven't had much success.<br>
> > > >><br>
> > > >> I don't think there's any documentation on this, but<br>
> it would<br>
> > > probably<br>
> > > >> be good to write up. Consistency in Swift is very<br>
> similar<br>
> > to S3.<br>
> > > >> That is, there aren't many non-eventual consistency<br>
> guarantees.<br>
> > > >><br>
> > > >> Listing updates can happen asynchronously (especially<br>
> under<br>
> > > load), and<br>
> > > >> older versions of files can show up in requests (deletes<br>
> > are just a<br>
> > > >> new "deleted" version of the file).<br>
> > > ><br>
> > > > Ah, ok. Thanks a lot for stating this so explicitly.<br>
> There seems<br>
> > > to be a<br>
> > > > lot of confusion about this, now I can at least point<br>
> people to<br>
> > > > something.<br>
> > > ><br>
> > > >> Swift can generally be relied on for read-after-write<br>
> > consistency,<br>
> > > >> like S3's regions other than the the US Standard region.<br>
> > The reason<br>
> > > >> S3 in US Standard doesn't have this guarantee is because<br>
> > it's more<br>
> > > >> geographically widespread - something Swift isn't good at<br>
> > yet. I can<br>
> > > >> imagine we'll have the same limitation when we get there.<br>
> > > ><br>
> > > > Do you mean read-after-create consistency? Because<br>
> below you<br>
> > say about<br>
> > > > read-after-write:<br>
> > > ><br>
> > > >>> - If I receive a (non-error) response to a PUT<br>
> request, am I<br>
> > > guaranteed<br>
> > > >>> that the object will be immediately included in all<br>
> object<br>
> > > listings in<br>
> > > >>> every possible situation?<br>
> > > >><br>
> > > >> Nope.<br>
> > > ><br>
> > > > ..so is there such a guarantee for PUTs of *new* objects<br>
> > (like S3 non<br>
> > > > us-classic), or does "can generally be relied on" just<br>
> mean<br>
> > that the<br>
> > > > chances for new puts are better?<br>
> > > ><br>
> > > >> Also like S3, Swift can't make any strong guarantees<br>
> about<br>
> > > >> read-after-update or read-after-delete consistency.<br>
> We do<br>
> > have an<br>
> > > >> "X-Newest" header that can be added to GETs and HEADs to<br>
> > make the<br>
> > > >> proxy do a quorum of backend servers and return the<br>
> newest<br>
> > available<br>
> > > >> version, which greatly improves these, at the cost of<br>
> latency.<br>
> > > ><br>
> > > > That sounds very interesting. Could you give some more<br>
> > details on what<br>
> > > > exactly is guaranteed when using this header? What happens<br>
> > if the<br>
> > > server<br>
> > > > having the newest copy is down?<br>
> > > ><br>
> > > >>> - If the swift server looses an object, will the<br>
> object name<br>
> > > still be<br>
> > > >>> returned in object listings? Will attempts to<br>
> retrieve it<br>
> > result<br>
> > > in 404<br>
> > > >>> errors (as if it never existed) or a different error?<br>
> > > >><br>
> > > >> It will show up in listings, but give a 404 when you<br>
> attempt to<br>
> > > >> retrieve it. I'm not sure how we can improve that<br>
> with Swift's<br>
> > > >> general model, but feel free to make suggestions.<br>
> > > ><br>
> > > > From an application programmers point of view, it<br>
> would be very<br>
> > > helpful<br>
> > > > if lost objects could be distinguished from non-existing<br>
> > object by a<br>
> > > > different HTTP error. Trying to access a non-existing<br>
> object may<br>
> > > > indicate a bug in the application, so it would be nice to<br>
> > know when it<br>
> > > > happens.<br>
> > > ><br>
> > > > Also, it would be very helpful if there was a way to list<br>
> > all lost<br>
> > > > objects without having to issue HEAD requests for every<br>
> > stored object.<br>
> > > > Could this information be added to the XML and JSON<br>
> output of<br>
> > > container<br>
> > > > listings? Then an application would have the chance to<br>
> > periodically<br>
> > > > check for lost data, rather than having to handle all lost<br>
> > objects at<br>
> > > > the instant they're required.<br>
> > > ><br>
> > > ><br>
> > > > I am working on a swift backend for S3QL<br>
> > > > (<a href="http://code.google.com/p/s3ql/" target="_blank">http://code.google.com/p/s3ql/</a>), a program that exposes<br>
> > online cloud<br>
> > > > storage as a local UNIX file system. To prevent data<br>
> > corruption, there<br>
> > > > are two requirements that I'm currently struggling to<br>
> > provide with the<br>
> > > > swift backend:<br>
> > > ><br>
> > > > - There needs to be a way to reliably check if one object<br>
> > (holding the<br>
> > > > file system metadata) is the newest version.<br>
> > > ><br>
> > > > The S3 backend does this by requiring storage in the non<br>
> > us-classic<br>
> > > > regions and using list-after-create consistency with a<br>
> > marker object<br>
> > > > that has has a "generation number" of the metadata<br>
> > embedded in its<br>
> > > > name.<br>
> > > ><br>
> > > > I'm not yet sure if this would work with swift as well<br>
> > (the google<br>
> > > > storage backend just relies on the strong<br>
> read-after-write<br>
> > > > consistency).<br>
> > > ><br>
> > > > - The file system checker needs a way to identify lost<br>
> objects.<br>
> > > ><br>
> > > > Here the S3 backend just relies on the durability<br>
> > guarantee that<br>
> > > > effectively no object will ever be lost.<br>
> > > ><br>
> > > > Again, I'm not sure how to implement this for swift.<br>
> > > ><br>
> > > ><br>
> > > > Any suggestions?<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Best,<br>
> > > ><br>
> > > > -Nikolaus<br>
> > > ><br>
> > ><br>
> > ><br>
> > > -Nikolaus<br>
> > ><br>
> > > --<br>
> > > »Time flies like an arrow, fruit flies like a Banana.«<br>
> > ><br>
> > > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8<br>
> > AE4E 425C<br>
> > ><br>
> > > _______________________________________________<br>
> > > Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> > > Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
> > <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>>><br>
> > > <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
> > <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>>>><br>
> > > Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> > > More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> > -Nikolaus<br>
> ><br>
> > --<br>
> > »Time flies like an arrow, fruit flies like a Banana.«<br>
> ><br>
> > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8<br>
> AE4E 425C<br>
> ><br>
> ><br>
><br>
><br>
> -Nikolaus<br>
><br>
> --<br>
> »Time flies like an arrow, fruit flies like a Banana.«<br>
><br>
> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C<br>
><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-Nikolaus<br>
<br>
--<br>
»Time flies like an arrow, fruit flies like a Banana.«<br>
<br>
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C<br>
</font></span></blockquote></div><br>