All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Fedotov <ifedotov@mirantis.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: Dev Meeting followup on compression
Date: Tue, 9 Feb 2016 16:24:49 +0300	[thread overview]
Message-ID: <56B9E8A1.5010805@mirantis.com> (raw)
In-Reply-To: <CAOi1vP9tGqqMVV+GmF4ikmvLecKkT21HVFWB=0Bnc5WCwoNyYA@mail.gmail.com>

Ilya,

please find my comments inline.

On 08.02.2016 22:23, Ilya Dryomov wrote:
> On Mon, Feb 8, 2016 at 5:34 PM, Igor Fedotov <ifedotov@mirantis.com> wrote:
>> Guys,
>>
>> let me summarize what we decided regarding compression support in Ceph
>> during the Dev Meeting last week.
>>
>> Below are possible implementation options, their pros/cons and the
>> conclusion.
>>
>> 1) Add compression support to RGW.
>> Pros/Cons:
>> + Simple
>> + Reduced inter-component traffic
>> - Limited to specific clients
>> - Will conflict with partial read/writes if any appear
>>
>> Alyona Kiseleva from Mirantis (akyseleva@mirantis.com) will start
>> implementing this promptly. You can ask additional questions to her via
>> e-mail or during daily RGW stendups she is planning to attend regularly.
>>
>> 2) Add basic compression support to BlueStore. Basic = "Append only"
>> functionality to be implemented. Specific "append only" hint/flag needs to
>> be introduced for object creation interface.
>>
>> Pros/Cons:
>> + Moderate complexity
>> + Suits for any client/PG backend
>> + Good isolation from other Ceph components
>> - Limited applicability
>> - additional 50-200% CPU load for the cluster since we compress each
>> replica/EC shard independently
>> - no inter-component traffic saving
>> - recovery procedure requires decompress/recompress sequence
> This is for EC pools only, right?  Can you elaborate on this bullet?
That's for any pool type. When compression takes place at object store 
level and recovery is performed at OSD(PGBackend instance) you need to 
retrieve an object replica from the store ( and hence decompress it ) 
and subsequently compress it back when saving at a new store .
Contrary having compress/decompress at PGBackend allows to bypass such 
decompress/compress overhead.

>> Mirantis ( me specifically ) will start blueprint/POC creation for this
>> promptly. I'm planning to attend daily RBD syncup regularly to inform on the
>> progress.
> Core standup and/or the new EC-overwrite meeting Sam is planning on
> holding is probably a better place for this.
Where can I find a schedule for these meetings?

> Thanks,
>
>                  Ilya
Regards,
Igor

  reply	other threads:[~2016-02-09 13:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 16:34 Dev Meeting followup on compression Igor Fedotov
2016-02-08 19:23 ` Ilya Dryomov
2016-02-09 13:24   ` Igor Fedotov [this message]
2016-02-09 15:34     ` Samuel Just

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=56B9E8A1.5010805@mirantis.com \
    --to=ifedotov@mirantis.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.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.