<div>The X-Newest header can be used by a GET Operation to ensure that all of the</div><div>Storage Nodes (3 by default) are queried for the latest copy of the Object.</div><div>The COPY Object operation already has this functionality.<br>
<br><div class="gmail_quote">On Fri, Jan 20, 2012 at 9:12 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>
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 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>> writes:<br>
>> On Tue, Jan 17, 2012 at 4:55 PM, Nikolaus Rath <<a href="mailto:Nikolaus@rath.org">Nikolaus@rath.org</a>> wrote:<br>
>>> Amazon S3 and Google Storage make very explicit (non-) consistency<br>
>>> guarantees for stored objects. I'm looking for a similar 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 it would probably<br>
>> be good to write up.  Consistency in Swift is very similar to S3.<br>
>> That is, there aren't many non-eventual consistency guarantees.<br>
>><br>
>> Listing updates can happen asynchronously (especially under load), and<br>
>> older versions of files can show up in requests (deletes are just a<br>
>> new "deleted" version of the file).<br>
><br>
> Ah, ok. Thanks a lot for stating this so explicitly. There seems to be a<br>
> lot of confusion about this, now I can at least point people to<br>
> something.<br>
><br>
>> Swift can generally be relied on for read-after-write consistency,<br>
>> like S3's regions other than the the US Standard region.  The reason<br>
>> S3 in US Standard doesn't have this guarantee is because it's more<br>
>> geographically widespread - something Swift isn't good at 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 below you say about<br>
> read-after-write:<br>
><br>
>>> - If I receive a (non-error) response to a PUT request, am I guaranteed<br>
>>> that the object will be immediately included in all object listings in<br>
>>> every possible situation?<br>
>><br>
>> Nope.<br>
><br>
> ..so is there such a guarantee for PUTs of *new* objects (like S3 non<br>
> us-classic), or does "can generally be relied on" just mean that the<br>
> chances for new puts are better?<br>
><br>
>> Also like S3, Swift can't make any strong guarantees about<br>
>> read-after-update or read-after-delete consistency.  We do have an<br>
>> "X-Newest" header that can be added to GETs and HEADs to make the<br>
>> proxy do a quorum of backend servers and return the newest available<br>
>> version, which greatly improves these, at the cost of latency.<br>
><br>
> That sounds very interesting. Could you give some more details on what<br>
> exactly is guaranteed when using this header? What happens if the server<br>
> having the newest copy is down?<br>
><br>
>>> - If the swift server looses an object, will the object name still be<br>
>>> returned in object listings? Will attempts to retrieve it result 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 attempt to<br>
>> retrieve it.  I'm not sure how we can improve that with Swift's<br>
>> general model, but feel free to make suggestions.<br>
><br>
> From an application programmers point of view, it would be very helpful<br>
> if lost objects could be distinguished from non-existing object by a<br>
> different HTTP error. Trying to access a non-existing object may<br>
> indicate a bug in the application, so it would be nice to know when it<br>
> happens.<br>
><br>
> Also, it would be very helpful if there was a way to list all lost<br>
> objects without having to issue HEAD requests for every stored object.<br>
> Could this information be added to the XML and JSON output of container<br>
> listings? Then an application would have the chance to periodically<br>
> check for lost data, rather than having to handle all lost 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 online cloud<br>
> storage as a local UNIX file system. To prevent data corruption, there<br>
> are two requirements that I'm currently struggling to provide with the<br>
> swift backend:<br>
><br>
> - There needs to be a way to reliably check if one object (holding the<br>
>   file system metadata) is the newest version.<br>
><br>
>   The S3 backend does this by requiring storage in the non us-classic<br>
>   regions and using list-after-create consistency with a marker object<br>
>   that has has a "generation number" of the metadata embedded in its<br>
>   name.<br>
><br>
>   I'm not yet sure if this would work with swift as well (the google<br>
>   storage backend just relies on the strong read-after-write<br>
>   consistency).<br>
><br>
> - The file system checker needs a way to identify lost objects.<br>
><br>
>   Here the S3 backend just relies on the durability 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>
<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>
<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>
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>
</font></span></blockquote></div><br></div>