All of lore.kernel.org
 help / color / mirror / Atom feed
From: Loic Dachary <loic@dachary.org>
To: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Erasure coding library API
Date: Tue, 02 Jul 2013 01:00:19 +0200	[thread overview]
Message-ID: <51D20A03.1030204@dachary.org> (raw)

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

Hi,

Today Sam pointed out that the API for LRC ( Xorbas Hadoop Project Page, Locally Repairable Codes (LRC) http://smahesh.com/HadoopUSC/ for instance ) would need to be different from the one initialy proposed:

    context(k, m, reed-solomon|...) => context* c 
    encode(context* c, void* data) => void* chunks[k+m]
    decode(context* c, void* chunk[k+m], int* indices_of_erased_chunks) => void* data // erased chunks are
not used
    repair(context* c, void* chunk[k+m], int* indices_of_erased_chunks) => void* chunks[k+m] // erased
chunks are rebuilt

The decode function must allow for partial read:

    decode(context* c, int offset, int length, void* chunk[k+m], int* indices_of_erased_chunks, int* missing_chunks) => void* data 

If there are not enough chunks to recover the desired data range [offset, offset+length) the function returns NULL and sets missing_chunks to the list of chunks that must be retrieved in order to be able to read the desired data.

If decode is called to read just 1 chunk and it is missing, reed-solomon would return on error and ask for all other chunks to repair. If the underlying library implements LRC, it would ask for a subset of the chunks. 

An implementation allowing only full reads and using jerasure ( which does not do LRC ) requires that offset is always zero, length is the size of the object and returns a copy of indices_of_erased_chunks if there are not enough chunks to rebuild the missing ones. 

Comments are welcome :-)

-- 
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 --]

             reply	other threads:[~2013-07-01 23:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01 23:00 Loic Dachary [this message]
2013-07-02 14:07 ` Erasure coding library API Atchley, Scott
2013-07-02 17:14   ` Atchley, Scott
2013-07-02 21:33     ` Samuel Just
2013-07-03  2:12       ` Paul Von-Stamwitz
2013-07-03 11:53         ` Atchley, Scott
2013-07-03 18:19           ` Paul Von-Stamwitz
2013-07-04  3:06           ` Paul Von-Stamwitz
2013-07-04 13:24             ` Loic Dachary
2013-07-05 12:13               ` Atchley, Scott
2013-07-05 14:06                 ` Loic Dachary
2013-07-05 15:02                   ` Atchley, Scott
2013-07-05 16:34                     ` Loic Dachary
2013-07-05 16:55                       ` Atchley, Scott
2013-07-05 12:39             ` Atchley, Scott
2013-07-05 16:50       ` 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=51D20A03.1030204@dachary.org \
    --to=loic@dachary.org \
    --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.