All of lore.kernel.org
 help / color / mirror / Atom feed
From: Loic Dachary <loic@dachary.org>
To: Xinze Chi <xmdxcxz@gmail.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Fwd: Reduce read latency and bandwidth for ec pool
Date: Tue, 17 Mar 2015 08:48:55 +0100	[thread overview]
Message-ID: <5507DC67.2030800@dachary.org> (raw)
In-Reply-To: <CANE=7sVcY5sCaHUSFn+MDkAYzeewa767ziXXLqNiSCXhnG4s-g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

Hi,

On 17/03/2015 08:27, Xinze Chi wrote:
> hi, loic:
> 
>    I have an idea which could reduce read latency and bandwidth for ec pool.
> 
>    But, I don't know whether it is feasible.
> 
>    Such as ec pool stripe_width = 16384 = 4 * 4096,  K = 4, M =2
> 
>    So ceph will partition the total of 16384 bytes to 4 data chunk,
> and encoding 2 parity chunk
> 
>    shard_0 include 0 - (4096-1) in original data;
>    shard_1 include 4096 - (4096*2 - 1) in original data;
>    shard_2 include 4096*2 - (4096 * 3 -1) in original data;
>    shard_3 include 4096*3 - (4096 * 4 - 1) in original data
>    shard_4 include parity chunk
>    shard_5 include parity chunk
> 
>     Now if client read (offset 0, len 4096) from object, it should
> read 4 shard (from 0-3) and decode all this 4 chunk.
> 
>     But, this example, maybe we can compute the destination shard
> based on ec pool config ,read offset and read len , we only read
> 
> shard_0 and return it to client, because shard_0 has include all data
> as client need.

That optimization makes sense to me. I guess you're interested in having small objects in the pool and only read a few bytes at a time ?

Cheers

> 
>     Wait for your comment.
> 
>     Thanks.
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

       reply	other threads:[~2015-03-17  7:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CANE=7sUo7tMT=kyuN86vs5b13nnqY9wpOuNuf=_z=P7UXKc+sg@mail.gmail.com>
     [not found] ` <CANE=7sVcY5sCaHUSFn+MDkAYzeewa767ziXXLqNiSCXhnG4s-g@mail.gmail.com>
2015-03-17  7:48   ` Loic Dachary [this message]
     [not found]     ` <CANE=7sV1CQA=ZV5ELihrE4DZNGN5=4c07uP4Pv2w8LLpzqWabA@mail.gmail.com>
2015-03-17  7:52       ` Fwd: Fwd: Reduce read latency and bandwidth for ec pool Xinze Chi
2015-03-17  8:02         ` Loic Dachary
     [not found]           ` <CANE=7sUR-Wdsat=3mBHW4SWrxSJPOC4svrZkwBMYQnWQFJ5VCw@mail.gmail.com>
2015-03-17  8:39             ` Loic Dachary
2015-03-17  8:45               ` Xinze Chi
2015-03-17  8:58                 ` Loic Dachary
2015-03-17 18:18                   ` Josh Durgin
2015-03-18  6:15                     ` Ning Yao

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=5507DC67.2030800@dachary.org \
    --to=loic@dachary.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=xmdxcxz@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.