From: Loic Dachary <loic@dachary.org>
To: Paul Von-Stamwitz <PVonStamwitz@us.fujitsu.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: Comments on Ceph distributed parity implementation
Date: Fri, 21 Jun 2013 10:29:17 +0200 [thread overview]
Message-ID: <51C40EDD.9090909@dachary.org> (raw)
In-Reply-To: <622F4407872BA447A16110F65453358C01A4D8066EE7@FMSAMAIL.fmsa.local>
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
On 06/21/2013 03:23 AM, Paul Von-Stamwitz wrote:
>
> On 06/20/2013 11:26 PM, Loic Dachary wrote:
>>
>> I wrote down a short description of the read/write path I plan to
>> implement in ceph :
> https://github.com/dachary/ceph/blob/wip-4929/doc/dev/osd_internals/erasure-code.rst.
>> A quick look at the drawings will hopefully give you an idea. Each OSD is > a disk connected to the others over the network. Although I chose K+M = 5 > I suspect the most common use case will be around K+M = 7+3 = 10
>
> Hi Loic,
>
> A couple questions regarding your proposal:
>
> Where would encode/decode occur? Client or OSD? Previous discussions seemed to want it at the OSD level. Your proposal seems that it could be either.
I think it should be in the OSD. Although it would be possible to implement it in the client, it would have to be implemented in the OSD anyway for scrubbing. Therefore I think it is simpler to implement it in the OSD as a first step.
>
> What about partial reads? For example, if only 'H' was requested, would you decode the entire object first?
Unless you see a good reason to implement this optimization from the start, I think the entire object would be decoded.
> Or, read from OSD1 and reconstruct on error?
I think that's what we want, ultimately. And also to encode / decode large objects (1GB for instance) as a sequence of independant regions (4MB for instance or smaller).
I updated https://github.com/dachary/ceph/blob/wip-4929/doc/dev/osd_internals/erasure-code.rst to reflect our discussion.
The first, simplest implementation is likely to be fit to use with RGW and probably too slow to use with RBD. Do you think we should try to optimize for RBD right now ?
Cheers
>
> Thanks,
> Paul
> --
> 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
--
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2013-06-21 8:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 20:13 Comments on Ceph distributed parity implementation Martin Flyvbjerg
2013-06-14 20:29 ` Mark Nelson
2013-06-14 21:05 ` Joe Buck
2013-06-14 22:57 ` Loic Dachary
2013-06-15 1:12 ` Paul Von-Stamwitz
2013-06-15 6:51 ` Loic Dachary
2013-06-16 19:51 ` Benoît Parrein
2013-06-16 21:31 ` Loic Dachary
2013-06-17 16:48 ` Benoît Parrein
2013-06-17 16:55 ` Paul Von-Stamwitz
2013-06-18 7:44 ` Benoît Parrein
2013-06-18 14:22 ` James Plank
2013-06-19 1:35 ` Paul Von-Stamwitz
2013-06-20 18:25 ` Loic Dachary
2013-06-21 1:23 ` Paul Von-Stamwitz
2013-06-21 8:29 ` Loic Dachary [this message]
2013-06-22 0:08 ` Paul Von-Stamwitz
2013-06-22 8:26 ` Loic Dachary
2013-06-24 2:26 ` Harvey Skinner
[not found] ` <C395B77B849187439280E1CF5FE1F2FA8990491B@G9W0337.americas.hpqcorp.net>
[not found] ` <CAJOObidVdjtiwk+xk5rwZi4=DBZ9GvTQnAkteCC0OhB_vyg6pg@mail.gmail.com>
[not found] ` <CAJOObicNGkweZbVSR-V8NA9YXaZucUpNm0y8Ph3X7EkE=pRG5g@mail.gmail.com>
2013-06-18 14:31 ` Harvey Skinner
2013-06-18 15:46 ` Loic Dachary
2013-06-15 7:30 ` Loic Dachary
2013-06-15 9:40 ` Leen Besselink
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=51C40EDD.9090909@dachary.org \
--to=loic@dachary.org \
--cc=PVonStamwitz@us.fujitsu.com \
--cc=ceph-devel@vger.kernel.org \
/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.