crc32 for erasure code

crc32 for erasure code

[Loic Dachary]

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

Hi,

Unless I'm mistaken, ceph_crc32() is currently used in master via the crc32c() method of bufferlist to:

* encode_with_checksum/decode_with_checksum a PGLog entry
* Message::decode_message/Message::encode_message a message via calc_*_crc 
* FileJournal::do_read_entry/FileJournal::prepare_single_write a journal entry
* for information in the report monitory command ( Monitor.cc )

Erasure coded chunks ( i.e. files ) will need checksums. Should this be implemented as an optional feature in ceph/src/os/FileStore.{h,cc} ? If the underlying filesystem does not provide this feature, FileStore would call ceph_crc32 each time the object is modified. A verification method would be exposed and used when scrubbing erasure coded pools.

Cheers

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

Re: crc32 for erasure code

[Gregory Farnum]

On Mon, Sep 23, 2013 at 1:34 AM, Loic Dachary <loic@dachary.org> wrote:
> Hi,
>
> Unless I'm mistaken, ceph_crc32() is currently used in master via the crc32c() method of bufferlist to:
>
> * encode_with_checksum/decode_with_checksum a PGLog entry
> * Message::decode_message/Message::encode_message a message via calc_*_crc
> * FileJournal::do_read_entry/FileJournal::prepare_single_write a journal entry
> * for information in the report monitory command ( Monitor.cc )
>
> Erasure coded chunks ( i.e. files ) will need checksums. Should this be implemented as an optional feature in ceph/src/os/FileStore.{h,cc} ? If the underlying filesystem does not provide this feature, FileStore would call ceph_crc32 each time the object is modified. A verification method would be exposed and used when scrubbing erasure coded pools.

You mean should checksums be optional in the FileStore, or should we
provide a plugin framework for using things other than crc32, or...?
:)
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com

Re: crc32 for erasure code

[Loic Dachary]

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



On 23/09/2013 18:59, Gregory Farnum wrote:
> On Mon, Sep 23, 2013 at 1:34 AM, Loic Dachary <loic@dachary.org> wrote:
>> Hi,
>>
>> Unless I'm mistaken, ceph_crc32() is currently used in master via the crc32c() method of bufferlist to:
>>
>> * encode_with_checksum/decode_with_checksum a PGLog entry
>> * Message::decode_message/Message::encode_message a message via calc_*_crc
>> * FileJournal::do_read_entry/FileJournal::prepare_single_write a journal entry
>> * for information in the report monitory command ( Monitor.cc )
>>
>> Erasure coded chunks ( i.e. files ) will need checksums. Should this be implemented as an optional feature in ceph/src/os/FileStore.{h,cc} ? If the underlying filesystem does not provide this feature, FileStore would call ceph_crc32 each time the object is modified. A verification method would be exposed and used when scrubbing erasure coded pools.
> 
> You mean should checksums be optional in the FileStore, or should we
> provide a plugin framework for using things other than crc32, or...?
> :)

Not really. I was under the impression that crc32 is good enough. I'm not sure where ( in the code path ) it should be used for erasure coded pools. In the FileStore ? Or in the erasure code PG to set an attribute of the object ? The FileStore seems to be more sensible but ... I'm not sure hence the mail ;-)

> -Greg
> Software Engineer #42 @ http://inktank.com | http://ceph.com
> 

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

Re: crc32 for erasure code

[Gregory Farnum]

On Mon, Sep 23, 2013 at 10:10 AM, Loic Dachary <loic@dachary.org> wrote:
>
>
> On 23/09/2013 18:59, Gregory Farnum wrote:
>> On Mon, Sep 23, 2013 at 1:34 AM, Loic Dachary <loic@dachary.org> wrote:
>>> Hi,
>>>
>>> Unless I'm mistaken, ceph_crc32() is currently used in master via the crc32c() method of bufferlist to:
>>>
>>> * encode_with_checksum/decode_with_checksum a PGLog entry
>>> * Message::decode_message/Message::encode_message a message via calc_*_crc
>>> * FileJournal::do_read_entry/FileJournal::prepare_single_write a journal entry
>>> * for information in the report monitory command ( Monitor.cc )
>>>
>>> Erasure coded chunks ( i.e. files ) will need checksums. Should this be implemented as an optional feature in ceph/src/os/FileStore.{h,cc} ? If the underlying filesystem does not provide this feature, FileStore would call ceph_crc32 each time the object is modified. A verification method would be exposed and used when scrubbing erasure coded pools.
>>
>> You mean should checksums be optional in the FileStore, or should we
>> provide a plugin framework for using things other than crc32, or...?
>> :)
>
> Not really. I was under the impression that crc32 is good enough. I'm not sure where ( in the code path ) it should be used for erasure coded pools. In the FileStore ? Or in the erasure code PG to set an attribute of the object ? The FileStore seems to be more sensible but ... I'm not sure hence the mail ;-)

Ah, I see. We currently use the CRC in two different ways:
1) For local and network checksums, making sure that what we read is
what was written — this is used in writing journal entries, and in
sending a message over the network, and lets us check for bit flips,
etc.
2) For comparing two different copies of any object during scrubbing
without shipping the whole object.

The first of these uses doesn't need any changing for erasure-coded
pools, which I believe means we don't need to change any of the
functions you've mentioned. However, we will need to do something else
for the second use case. Luckily we've already started that as it's in
the scrub code and part of the functionality split that's already
under way. :)
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
--
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