All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhishek L <abhishek.lekshmanan@gmail.com>
To: Yehuda Sadeh-Weinraub <yehuda@redhat.com>
Cc: Abhishek Lekshmanan <abhishek@suse.com>,
	Ceph Devel <ceph-devel@vger.kernel.org>
Subject: Re: RGW Multisite delete wierdness
Date: Tue, 19 Apr 2016 19:54:18 +0200	[thread overview]
Message-ID: <86oa95lc1h.fsf@linux-stsn.suse> (raw)
In-Reply-To: <CADRKj5TpcOzavirV7M-s2s8hg+9yyHm3LUyV_Mw3eCDR3DLzSw@mail.gmail.com>


Yehuda Sadeh-Weinraub writes:

> On Tue, Apr 19, 2016 at 9:10 AM, Abhishek Lekshmanan <abhishek@suse.com> wrote:
>> Trying deleting objects & buckets from a secondary zone in a RGW
>> multisite configuration leads to some wierdness:
>>
>> 1. On deleting an object and the bucket immediately will mostly lead to
>> object and bucket getting deleted in the secondary zone, but since we
>> forward the bucket deletion to master only after we delete in secondary
>> it will fail with 409 (BucketNotEmpty) and gets reraised as a 500 to the
>> client. This _seems_ simple enough to fix if we forward the bucket
>> deletion request to master zone before attempting deletion locally,
>> (issue: http://tracker.ceph.com/issues/15540, possible fix: https://github.com/ceph/ceph/pull/8655)
>>
>
> Yeah, this looks good. We'll get it through testing.
>
>> 2. Deletion of objects themselves: deletion of objects themselves seems
>> to be a bit racy, deleting an object on a secondary zone succeeds,
>> listing the bucket seems to show an empty list, but gets populated with
>> the object again sometimes (this time with a newer timestamp), this is
>> not always guaranteed to be reproduce, but I've seen this often with
>> multipart uploads, as an eg:
>>
>> $ s3 -u list test-mp
>>                        Key                             Last Modified      Size
>> --------------------------------------------------  --------------------  -----
>> test.img                                            2016-04-19T13:00:17Z    40M
>> $ s3 -u delete test-mp/test.img
>> $ s3 -u list test-mp
>>                        Key                             Last Modified      Size
>> --------------------------------------------------  --------------------  -----
>> test.img                                            2016-04-19T13:00:45Z    40M
>> $ s3 -u delete test-mp/test.img # wait for a  min
>> $ s3 -us list test-mp
>> --------------------------------------------------  --------------------  -----
>> test.img                                            2016-04-19T13:01:52Z    40M
>>
>>
>> Mostly seeing log entries of this form in both the cases ie. where
>> delete object seems to be successfully delete in both master and
>> secondary zone and the case where it succeeds in master and fails in
>> secondary :
>>
>> 20 parsed entry: id=00000000027.27.2 iter->object=foo iter->instance= name=foo instance= ns=
>> 20 [inc sync] skipping object: dkr:d8e0ec3d-b3da-43f8-a99b-38a5b4941b6f.14113.2:-1/foo: non-complete operation
>> 20 parsed entry: id=00000000028.28.2 iter->object=foo iter->instance= name=foo instance= ns=
>> 20 [inc sync] skipping object: dkr:d8e0ec3d-b3da-43f8-a99b-38a5b4941b6f.14113.2:-1/foo: canceled operation
>>
>> Any ideas on this?
>>
>
> Do you have more than 2 zones syncing? Is it an object delete that
> came right after the object creation?

Only 2 zones ie. one master and one secondary, req, on secondary. The delete came right after the
create though 
>
> Yehuda


-- 
Abhishek

  reply	other threads:[~2016-04-19 17:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 16:10 RGW Multisite delete wierdness Abhishek Lekshmanan
2016-04-19 17:52 ` Yehuda Sadeh-Weinraub
2016-04-19 17:54   ` Abhishek L [this message]
2016-04-19 18:08     ` Yehuda Sadeh-Weinraub
2016-04-22  0:40       ` Yehuda Sadeh-Weinraub
2016-04-25  8:17         ` Abhishek Lekshmanan
2016-04-25 18:46           ` Yehuda Sadeh-Weinraub
2016-04-25 19:44             ` Abhishek L
2016-04-26 17:37               ` Abhishek Lekshmanan
2016-04-26 22:21                 ` Yehuda Sadeh-Weinraub
2016-04-26 23:12                   ` Yehuda Sadeh-Weinraub
2016-04-27 20:02                     ` Abhishek L
2016-04-27 20:15                       ` Yehuda Sadeh-Weinraub
2016-04-27 21:50                         ` Yehuda Sadeh-Weinraub
2016-05-31  9:21                           ` Abhishek Lekshmanan
2016-05-31 11:06                             ` Yehuda Sadeh-Weinraub
2016-06-02 13:01                               ` Abhishek Lekshmanan
2016-06-02 13:09                                 ` Yehuda Sadeh-Weinraub
2016-06-03  8:28                                   ` Abhishek Lekshmanan
2016-06-03  9:00                                     ` Yehuda Sadeh-Weinraub
2016-06-03  9:09                                       ` Yehuda Sadeh-Weinraub
2016-06-03  9:16                                       ` Abhishek Lekshmanan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86oa95lc1h.fsf@linux-stsn.suse \
    --to=abhishek.lekshmanan@gmail.com \
    --cc=abhishek@suse.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=yehuda@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.