[Openstack] Swift Consistency Guarantees?

Thomas, Duncan duncan.thomas at hp.com
Wed Feb 1 16:35:04 UTC 2012


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 not stale
> >
> > 2) get a recent copy from swift  (when setting no cache)
> >
> > 3) do a quorum call on all the storage nodes to get the most accurate
> answer swift can provide.
> >
> >
> > You're proposing that 2 & 3 are the same, since they're both
> different than 1. But their performance implications on 2 & 3 are quite
> different.
> 
> Effectively. My point, however, is that inventing new mechanisms --
> especially new headers -- should be avoided if possible, as they
> generally cause more trouble than they're worth.
> 
> Is there really a use case for #2 being distinct from #3?
> 
> If there is, it'd be better expressed as a new Cache-Control request
> directive (e.g., Cache-Control: authoritative), next time things get
> revised.

It isn't a caching directive though, it's asking for a change of behavior on the part of the swift server...




More information about the Openstack mailing list