Open Stack

Taking a "snapshot" of swift seems counterintuitive to me.  It seems like
there would be a number of gaps -  no locking to allow for a consistent
image, PUT overwrites are immediate, no index of deltas between snapshots.
 Maybe I misunderstand your goal.

I don't believe container sync shouldn't send multiple PUT requests with
the whole object.  Each container keeps an index of the last row synced and
co-ordinate's with the other replicas using a modulo schema.  Eventually
there's a tail sweep to make sure everything is caught up, but I thought it
did a HEAD or a if-not-match check.  I may be mistaken.  It's been awhile
since I've looked at that code closely - maybe I'll have an opportunity to
do that soon.  If you are getting a bunch of un-needed transfer across the
wire it may be a bug. Perhaps you could provide a simple detailed scenario
that will reproduce the undesirable behavior.

-Clay


On Tue, Aug 6, 2013 at 5:41 AM, <kajinamit at nttdata.co.jp> wrote:

> Hi,****
>
> ** **
>
> ** **
>
> I’m interested in container-sync to take a snapshot of swift.****
>
> ** **
>
> I want to sync data between two swift clusters distributed in multiple
> locations.****
>
> It is assumed that there are two swift clusters located in two places,****
>
> and the container-sync syncs data from one cluster to the other cluster
> through WAN.****
>
> ** **
>
> I tried container-sync with Folsom in this case, and faced one problem
> with this scenario.****
>
> Container-sync always sends multiple PUT request with whole object
> transfer,****
>
> which puts pressure on network bandwidth between swift clusters.****
>
> ** **
>
> I checked Grizzly and latest 1.9.0, but I cannot find any progress with
> the issues.****
>
> Does anyone experiences similar issues or tackled to improve performance?*
> ***
>
> ** **
>
> IMHO, it may be fixed with a little changes to the container-sync.****
>
> If it can be, I'd like to try it. :-)****
>
> ** **
>
> Does anybody have any idea or suggestions?****
>
> ** **
>
> Thanks in advance.****
>
> Takashi Kajinami****
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130809/4acf6828/attachment.html>