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, <kajina...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
