From: Alex Elder <elder@ieee.org>
To: Ilya Dryomov <ilya.dryomov@inktank.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH] rbd: don't treat CEPH_OSD_OP_DELETE as extent op
Date: Mon, 24 Nov 2014 11:46:51 -0600 [thread overview]
Message-ID: <54736F0B.6030702@ieee.org> (raw)
In-Reply-To: <CALFYKtB1qOj0d4eGdKGe=kS3-u+odgGFt-euSt5Zhshs8RXbPw@mail.gmail.com>
On 11/24/2014 07:30 AM, Ilya Dryomov wrote:
> On Mon, Nov 24, 2014 at 3:23 PM, Alex Elder <elder@ieee.org> wrote:
>> On 11/24/2014 03:59 AM, Ilya Dryomov wrote:
>>> CEPH_OSD_OP_DELETE is not an extent op, stop treating it as such. This
>>> sneaked in with discard patches - it's one of the three osd ops (the
>>> other two are CEPH_OSD_OP_TRUNCATE and CEPH_OSD_OP_ZERO) that discard
>>> is implemented with.
>>>
>>> Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
>>
>> Is the CEPH_OSD_OP_DELETE used in ceph_zero_partial_object()
>> an extent op? If it is not, you should get rid of the BUG_ON()
>> in osd_req_op_extent_init() that allows CEPH_OSD_OP_DELETE.
>>
>> And if that's the case it looks like that function or
>> ceph_osdc_new_request() handle CEPH_OSD_OP_DELETE
>> properly--so it's not treated as an extent op.
>>
>> And: osd_req_encode_op() encodes a CEPH_OSD_OP_DELETE
>> as an extent op as well.
>>
>> If it *can* be an extent op (but just not as used by RBD)
>> then it warrants a comment here that explains why it is
>> not being initialized as an extent op.
>
> Hi Alex,
>
> Clearly I didn't provide enough background.
>
> OSDs don't look at extent part of the op union when processing
> CEPH_OSD_OP_DELETE, so it's not an extent op.
>
> Zheng added support for CEPH_OSD_OP_CREATE and in the same commit
> changed osd_req_op_extent_init(), ceph_osdc_new_request() and
> osd_req_encode_op() to not allow/encode CEPH_OSD_OP_DELETE, see [1].
> This patch was rebased into testing before [1] in order to not break
> git bisect as Zheng didn't care of rbd, which only recently started
> issuing CEPH_OSD_OP_DELETE for whole-object discards.
So it sounds like my concerns were addressed in the Zheng's
original patch. RBD didn't used to use OP_DELETE, and once it
did, the fact that it encoded it as an extent op didn't matter
because the OSD ignored anything it sent for the extent.
Therefore this is just cleaning up RBD code that was not
exhibiting erroneous behavior.
I'm sorry I didn't update my tree before reviewing the patch...
Reviewed-by: Alex Elder <elder@linaro.org>
> [1] https://github.com/ceph/ceph-client/commit/6d23aa137d1861fc48f86ba6532458fcebcdd038
>
> Thanks,
>
> Ilya
>
prev parent reply other threads:[~2014-11-24 17:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 9:59 [PATCH] rbd: don't treat CEPH_OSD_OP_DELETE as extent op Ilya Dryomov
2014-11-24 12:23 ` Alex Elder
2014-11-24 13:30 ` Ilya Dryomov
2014-11-24 17:46 ` Alex Elder [this message]
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=54736F0B.6030702@ieee.org \
--to=elder@ieee.org \
--cc=ceph-devel@vger.kernel.org \
--cc=ilya.dryomov@inktank.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.