CEPH filesystem development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox