From: Loic Dachary <loic@dachary.org>
To: Andreas Joachim Peters <Andreas.Joachim.Peters@cern.ch>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: CEPH Erasure Encoding + OSD Scalability
Date: Fri, 05 Jul 2013 23:23:44 +0200 [thread overview]
Message-ID: <51D73960.3070303@dachary.org> (raw)
In-Reply-To: <3472A07E6605974CBC9BC573F1BC02E494B06990@PLOXCHG04.cern.ch>
[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]
Hi Andreas,
On 04/07/2013 23:01, Andreas Joachim Peters wrote:> Hi Loic,
> thanks for the responses!
>
> Maybe this is useful for your erasure code discussion:
>
> as an example in our RS implementation we chunk a data block of e.g. 4M into 4 data chunks of 1M. Then we create a 2 parity chunks.
>
> Data & parity chunks are split into 4k blocks and these 4k blocks get a CRC32C block checksum each (SSE4.2 CPU extension => MIT library or BTRFS). This creates 0.1% volume overhead (4 bytes per 4096 bytes) - nothing compared to the parity overhead ...
>
> You can now easily detect data corruption using the local checksums and avoid to read any parity information and (C)RS decoding if there is no corruption detected. Moreover CRC32C computation is distributed over several (in this case 4) machines while (C)RS decoding would run on a single machine where you assemble a block ... and CRC32C is faster than (C)RS decoding (with SSE4.2) ...
What does (C)RS mean ? (C)Reed-Solomon ?
> In our case we write this checksum information separate from the original data ... while in a block-based storage like CEPH it would be probably inlined in the data chunk.
> If an OSD detects to run on BRTFS or ZFS one could disable automatically the CRC32C code.
Nice. I did not know that was built-in :-)
https://github.com/dachary/ceph/blob/wip-4929/doc/dev/osd_internals/erasure-code.rst#scrubbing
> (wouldn't CRC32C be also useful for normal CEPH block replication? )
I don't know the details of scrubbing but it seems CRC is already used by deep scrubbing
https://github.com/ceph/ceph/blob/master/src/osd/PG.cc#L2731
Cheers
> As far as I know with the RS CODEC we use you can either miss stripes (data =0) in the decoding process but you cannot inject corrupted stripes into the decoding process, so the block checksumming is important.
>
> Cheers Andreas.
--
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: 261 bytes --]
next parent reply other threads:[~2013-07-05 21:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3472A07E6605974CBC9BC573F1BC02E494B06990@PLOXCHG04.cern.ch>
2013-07-05 21:23 ` Loic Dachary [this message]
2013-07-06 13:45 ` CEPH Erasure Encoding + OSD Scalability Andreas Joachim Peters
2013-07-06 15:28 ` Mark Nelson
2013-07-06 20:43 ` Loic Dachary
2013-07-08 15:38 ` Mark Nelson
[not found] ` <CAGhffvx5-xmprT-vL1VNrz12+pJSikg1WsUqy_JRdW0JNm5auQ@mail.gmail.com>
2013-07-06 20:47 ` Loic Dachary
2013-07-07 21:04 ` Andreas Joachim Peters
2013-07-08 3:37 ` Sage Weil
2013-07-08 10:00 ` Andreas Joachim Peters
2013-07-08 10:31 ` Loic Dachary
2013-07-08 15:47 ` Sage Weil
2013-08-19 10:35 ` Loic Dachary
2013-08-22 21:50 ` Andreas Joachim Peters
[not found] ` <CAGhffvwB87a+1294BjmPrfu0a9hYdu17N-eHOvYCHWMXDLcJmA@mail.gmail.com>
2013-08-22 23:03 ` Loic Dachary
[not found] ` <CAGhffvxW9sG5LtcF-tU1YGkCMAQUfh2WW_3N=f=-vWs48vyxkQ@mail.gmail.com>
2013-08-24 19:41 ` Loic Dachary
2013-08-25 11:49 ` Loic Dachary
2013-09-14 14:59 ` Andreas Joachim Peters
2013-09-14 18:04 ` Loic Dachary
2013-09-22 23:00 Andreas Joachim Peters
2013-09-23 7:27 ` Loic Dachary
2013-09-23 9:37 ` Andreas Joachim Peters
2013-09-23 15:43 ` Andreas Joachim Peters
2013-09-25 15:14 ` Loic Dachary
2013-09-25 18:33 ` Andreas Joachim Peters
2013-09-25 18:48 ` Loic Dachary
2013-09-25 18:53 ` Sage Weil
[not found] ` <CAGhffvz1TYYLoqn0tps1HiLObSCv7H0ZNVgOd0raicGqgRuukA@mail.gmail.com>
2013-09-26 19:18 ` Loic Dachary
2013-09-26 21:49 ` Andreas Joachim Peters
2013-09-27 9:40 ` Loic Dachary
2013-10-01 23:00 ` Andreas Joachim Peters
2013-10-02 10:04 ` Loic Dachary
2013-10-02 10:15 ` Loic Dachary
[not found] <-7369304096744919226@unknownmsgid>
2013-09-20 11:35 ` Andreas Joachim Peters
2013-09-20 12:33 ` Loic Dachary
2013-09-20 13:19 ` Mark Nelson
2013-09-20 15:36 ` Sage Weil
2013-09-20 16:49 ` Loic Dachary
2013-09-21 15:11 ` Loic Dachary
2013-09-22 7:26 ` Andreas Joachim Peters
2013-09-22 9:41 ` Loic Dachary
2013-11-12 1:11 ` Andreas Joachim Peters
2013-11-12 18:06 ` Loic Dachary
2013-11-19 11:35 ` Andreas Joachim Peters
2013-12-09 16:45 ` Loic Dachary
2013-12-09 17:03 ` Mark Nelson
2013-12-10 8:43 ` Loic Dachary
2013-12-11 9:49 ` Andreas Joachim Peters
2013-12-11 12:28 ` Loic Dachary
2013-12-11 13:00 ` Mark Nelson
2013-12-13 15:47 ` Andreas Joachim Peters
2013-12-13 16:42 ` Loic Dachary
[not found] <CAGhffvws=OabwJHi+7n=SOg+YNxAnU=Zt8WLVZtvf1neHZQYhw@mail.gmail.com>
2013-07-04 13:07 ` Loic Dachary
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=51D73960.3070303@dachary.org \
--to=loic@dachary.org \
--cc=Andreas.Joachim.Peters@cern.ch \
--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.