Mark Nottingham wrote:
>On 31/01/2012, at 2:48 PM, andi abes wrote:
>> The current semantics allow you to do
> >
> >1) the the most recent cached copy, using the http caching mechanism. This
> >will ignore any updates to the swift cluster, as long as the cache is not
> >stale
> >
> >2) get a
Mark Nottingham on 01 February 2012 05:19 wrote:
> On 31/01/2012, at 2:48 PM, andi abes wrote:
>
> > The current semantics allow you to do
> >
> > 1) the the most recent cached copy, using the http caching mechanism.
> This will ignore any updates to the swift cluster, as long as the cache
> is no
On 31/01/2012, at 2:48 PM, andi abes wrote:
> The current semantics allow you to do
>
> 1) the the most recent cached copy, using the http caching mechanism. This
> will ignore any updates to the swift cluster, as long as the cache is not
> stale
>
> 2) get a recent copy from swift (when s
On Mon, Jan 30, 2012 at 5:51 PM, Mark Nottingham wrote:
>
> On 31/01/2012, at 4:45 AM, Caitlin Bestler wrote:
>
> > Mark Nottingham asked:
> >
> >> Why not just use
> >> Cache-Control: no-cache?
> >
> >> That way, intervening caches will do the right thing too...
> >
> >
> > Even with no caching
On 31/01/2012, at 4:45 AM, Caitlin Bestler wrote:
> Mark Nottingham asked:
>
>> Why not just use
>> Cache-Control: no-cache?
>
>> That way, intervening caches will do the right thing too...
>
>
> Even with no caching anywhere you still have N replicas (typically three)
> that will be update
Mark Nottingham asked:
>Why not just use
> Cache-Control: no-cache?
>That way, intervening caches will do the right thing too...
Even with no caching anywhere you still have N replicas (typically three) that
will be updated in an arbitrary order,
and clients that read from any one of those r
Why not just use
Cache-Control: no-cache
?
That way, intervening caches will do the right thing too...
Cheers,
On 21/01/2012, at 4:33 AM, Stephen Broeker wrote:
> The X-Newest header can be used by a GET Operation to ensure that all of the
> Storage Nodes (3 by default) are queried for the l
Hi Chuck,
Thanks for the detailed explanation! That pretty much answers all of my
questions. I think this can (and should) placed as-is somewhere in the
Swift Dokumentation and/or the Wiki.
Best,
Nikolaus
On 01/20/2012 04:58 PM, Chuck Thier wrote:
> Some general notes for consistency and swift (
On 01/20/2012 05:08 PM, Caitlin Bestler wrote:
> If you aren’t forcing a Get to reference all servers, using the option
> Stephen mentioned, then you MAY get an
> old version before the replication process is complete. That is what is
> meant by “eventual consistency”.
Well, but apparently this ma
You would need to have the following occur, to make your scenario plausible:
* you write the object, which places it on a majority of the replica nodes
(i.e. 2 out of 3)
* replication is slowly churning away, but doesn't quite catch up
* both the nodes that have the updated data fail simultaneousl
nice reply ;)
On Fri, Jan 20, 2012 at 6:35 PM, Pete Zaitcev wrote:
> On Fri, 20 Jan 2012 15:17:32 -0500
> Nikolaus Rath wrote:
>
> > Thanks! So there is no way to reliably get the most-recent version of an
> > object under all conditions.
>
> If you bend the conditions hard enough to hit the CA
On 01/20/2012 06:35 PM, Pete Zaitcev wrote:
> On Fri, 20 Jan 2012 15:17:32 -0500
> Nikolaus Rath wrote:
>
>> Thanks! So there is no way to reliably get the most-recent version of an
>> object under all conditions.
>
> If you bend the conditions hard enough to hit the CAP theorem, you do.
From w
On Fri, 20 Jan 2012 15:17:32 -0500
Nikolaus Rath wrote:
> Thanks! So there is no way to reliably get the most-recent version of an
> object under all conditions.
If you bend the conditions hard enough to hit the CAP theorem, you do.
-- Pete
___
Maili
Hi Andi,
My perspective is that I'm working on an application that should work
with arbitrary service providers using swift. Therefore, I'm interested
in the minimal set of guarantees that I can always rely on, no matter
how the service provider has configured his particular swift instance.
Best,
A new put can only succeed if it has successfully updated a full majority of
the replicas (typically 2 out of 3).
Therefore two different updates cannot concurrently succeed, one of them has to
know that it is the later transaction.
If you aren't forcing a Get to reference all servers, using the
Some general notes for consistency and swift (all of the below assumes
3 replicas):
Objects:
When swift PUTs an object, it attempts to write to all 3 replicas
and only returns success if 2 or more replicas were written
successfully. When a new object is created, it has a fairly strong
consiste
I'm finding this thread a bit confusing. You're comparing offered SERVICES
to Software. While some of the details of the software will dictate what's
possible, some are heavily dependent on how you deploy the swift software,
and what kind of deployment decisions you (or your service provider) make.
Actually I got that wrong for GET swift would try to serve the object even
if there is only one replica left for PUT it would need to have at least 2
successful write to succeed assuming you have a 3 replicas cluster.
On Fri, Jan 20, 2012 at 2:06 PM, Chmouel Boudjnah wrote:
> As Stephen mentionne
Hmm, but if there are e.g. 4 replicas, two of which are up-to-date but
offline, and two available but online, swift would serve the old version?
-Niko
On 01/20/2012 03:06 PM, Chmouel Boudjnah wrote:
> As Stephen mentionned if there is only one replica left Swift would not
> serve it.
>
> Chmoue
Hi,
Thanks! So there is no way to reliably get the most-recent version of an
object under all conditions.
Does the same apply to object listings? I.e., when a PUT of a new object
returns, can I construct a situation where a subsequent listing of the
container contents will not include the new obj
As Stephen mentionned if there is only one replica left Swift would not
serve it.
Chmouel.
On Fri, Jan 20, 2012 at 1:58 PM, Nikolaus Rath wrote:
> Hi,
>
> Sorry for being so persistent, but I'm still not sure what happens if
> the 2 servers that carry the new replica are down, but the 1 server
In this case, I believe that the GET will succeed.
On Fri, Jan 20, 2012 at 11:58 AM, Nikolaus Rath wrote:
> Hi,
>
> Sorry for being so persistent, but I'm still not sure what happens if
> the 2 servers that carry the new replica are down, but the 1 server that
> has the old replica is up. Will G
Hi,
Sorry for being so persistent, but I'm still not sure what happens if
the 2 servers that carry the new replica are down, but the 1 server that
has the old replica is up. Will GET fail or return the old replica?
Best,
Niko
On 01/20/2012 02:52 PM, Stephen Broeker wrote:
> By default there are
By default there are 3 replicas.
A PUT Object will return after 2 replicas are done.
So if all nodes are up then there are at least 2 replicas.
If all replica nodes are down, then the GET Object will fail.
On Fri, Jan 20, 2012 at 11:21 AM, Nikolaus Rath wrote:
> Hi,
>
> So if an object update ha
Hi,
So if an object update has not yet been replicated on all nodes, and all
nodes that have been updated are offline, what will happen? Will swift
recognize this and give me an error, or will it silently return the
older version?
Thanks,
Nikolaus
On 01/20/2012 02:14 PM, Stephen Broeker wrote:
If a node is down, then it is ignored.
That is the whole point about 3 replicas.
On Fri, Jan 20, 2012 at 10:43 AM, Nikolaus Rath wrote:
> Hi,
>
> What happens if one of the nodes is down? Especially if that node holds
> the newest copy?
>
> Thanks,
> Nikolaus
>
> On 01/20/2012 12:33 PM, Stephen
Hi,
What happens if one of the nodes is down? Especially if that node holds
the newest copy?
Thanks,
Nikolaus
On 01/20/2012 12:33 PM, Stephen Broeker wrote:
> The X-Newest header can be used by a GET Operation to ensure that all of the
> Storage Nodes (3 by default) are queried for the latest co
The X-Newest header can be used by a GET Operation to ensure that all of the
Storage Nodes (3 by default) are queried for the latest copy of the Object.
The COPY Object operation already has this functionality.
On Fri, Jan 20, 2012 at 9:12 AM, Nikolaus Rath wrote:
> Hi,
>
> No one able to furthe
Hi,
No one able to further clarify this?
Does swift offer there read-after-create consistence like
non-us-standard S3? What are the precise syntax and semantics of
X-Newest header?
Best,
Nikolaus
On 01/18/2012 10:15 AM, Nikolaus Rath wrote:
> Michael Barton writes:
>> On Tue, Jan 17, 2012 at
Michael Barton writes:
> On Tue, Jan 17, 2012 at 4:55 PM, Nikolaus Rath wrote:
>> Amazon S3 and Google Storage make very explicit (non-) consistency
>> guarantees for stored objects. I'm looking for a similar documentation
>> about OpenStack's Swift, but haven't had much success.
>
> I don't thin
On Tue, Jan 17, 2012 at 4:55 PM, Nikolaus Rath wrote:
> Amazon S3 and Google Storage make very explicit (non-) consistency
> guarantees for stored objects. I'm looking for a similar documentation
> about OpenStack's Swift, but haven't had much success.
I don't think there's any documentation on t
Hello,
Amazon S3 and Google Storage make very explicit (non-) consistency
guarantees for stored objects. I'm looking for a similar documentation
about OpenStack's Swift, but haven't had much success.
Could someone summarize what kind of consistency guarantees a swift
server offers?
For example:
32 matches
Mail list logo
