* Data-at-rest compression at EC pools blueprint
@ 2015-09-30 15:44 Igor Fedotov
2015-09-30 18:40 ` Samuel Just
0 siblings, 1 reply; 3+ messages in thread
From: Igor Fedotov @ 2015-09-30 15:44 UTC (permalink / raw)
To: ceph-devel
Folks,
I've just added a blueprint about adding compression to EC pools as per
our previous discussion.
Please find it at
http://tracker.ceph.com/projects/ceph/wiki/Submissions
Not sure I did that in proper manner - by attaching a new file. Other
blueprints look different at this page. Can't undo though.
Sorry about that.
And please point out different way to publish my blueprint if needed.
Any way - comments and reviews on the content are welcome.
Thanks.,
Igor.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Data-at-rest compression at EC pools blueprint
2015-09-30 15:44 Data-at-rest compression at EC pools blueprint Igor Fedotov
@ 2015-09-30 18:40 ` Samuel Just
2015-10-01 12:43 ` Igor Fedotov
0 siblings, 1 reply; 3+ messages in thread
From: Samuel Just @ 2015-09-30 18:40 UTC (permalink / raw)
To: Igor Fedotov; +Cc: ceph-devel
Seems like a reasonable start. Quick back-of-the-envelope calculation
suggests 2k of (logical_offset, compressed_offset) pairs per 1MB of
data with 8MB/pair and 4k chunks, which is probably ok to stuff into
an xattr. You should restructure the blueprint to make it independent
of EC. ReplicatedPG can do this before feeding the writes to the
backend (whichever backend is used) -- the pool alignment parameter
could be set on a replicated pool to enforce aligned appends on a
compressed replicated pool.
-Sam
On Wed, Sep 30, 2015 at 8:44 AM, Igor Fedotov <ifedotov@mirantis.com> wrote:
> Folks,
>
> I've just added a blueprint about adding compression to EC pools as per our
> previous discussion.
> Please find it at
> http://tracker.ceph.com/projects/ceph/wiki/Submissions
>
> Not sure I did that in proper manner - by attaching a new file. Other
> blueprints look different at this page. Can't undo though.
> Sorry about that.
>
> And please point out different way to publish my blueprint if needed.
>
> Any way - comments and reviews on the content are welcome.
>
> Thanks.,
> Igor.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Data-at-rest compression at EC pools blueprint
2015-09-30 18:40 ` Samuel Just
@ 2015-10-01 12:43 ` Igor Fedotov
0 siblings, 0 replies; 3+ messages in thread
From: Igor Fedotov @ 2015-10-01 12:43 UTC (permalink / raw)
To: Samuel Just; +Cc: ceph-devel
Samuel,
thanks a lot for prompt feedback.
On 30.09.2015 21:40, Samuel Just wrote:
> Seems like a reasonable start. Quick back-of-the-envelope calculation
> suggests 2k of (logical_offset, compressed_offset) pairs per 1MB of
> data with 8MB/pair and 4k chunks, which is probably ok to stuff into
> an xattr. You should restructure the blueprint to make it independent
> of EC. ReplicatedPG can do this before feeding the writes to the
> backend (whichever backend is used) --
I probably understand your concerns about having code unrelated to
Erasure Coding at EC pool level. But there is a couple of issues with
such a split:
1) Direct EC pool users are unable to benefit from compression. Sage
mentioned the need for that during our previous discussion.
2) Users are unable to access "compressed" data if cache tier has gone
or they intentionally bypass it. E.g. this might be caused by cache tier
removal/disablement. Despite that's probably an artificial use case but
it's easily reproducible in current Ceph deployments.
Given that I'd prefer to start considering EC pools as "low-cost
backing" pools with more or less equal space saving features
(compression and EC) rather than Erasure Code stuff with embedded
compression... Surely this is rather word/conception juggling....
Anyway I'm open to other suggestions how one can overcome mentioned
drawbacks.
> the pool alignment parameter
> could be set on a replicated pool to enforce aligned appends on a
> compressed replicated pool.
IMO replicated pool ( I thinks that's rather cache tier agent) already
performs aligned appends to backing storage.
Thanks,
Igor.
> -Sam
>
> On Wed, Sep 30, 2015 at 8:44 AM, Igor Fedotov <ifedotov@mirantis.com> wrote:
>> Folks,
>>
>> I've just added a blueprint about adding compression to EC pools as per our
>> previous discussion.
>> Please find it at
>> http://tracker.ceph.com/projects/ceph/wiki/Submissions
>>
>> Not sure I did that in proper manner - by attaching a new file. Other
>> blueprints look different at this page. Can't undo though.
>> Sorry about that.
>>
>> And please point out different way to publish my blueprint if needed.
>>
>> Any way - comments and reviews on the content are welcome.
>>
>> Thanks.,
>> Igor.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-10-01 12:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-30 15:44 Data-at-rest compression at EC pools blueprint Igor Fedotov
2015-09-30 18:40 ` Samuel Just
2015-10-01 12:43 ` Igor Fedotov
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.