* crc32 for erasure code
@ 2013-09-23 8:34 Loic Dachary
2013-09-23 16:59 ` Gregory Farnum
0 siblings, 1 reply; 4+ messages in thread
From: Loic Dachary @ 2013-09-23 8:34 UTC (permalink / raw)
To: Ceph Development
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: crc32 for erasure code 2013-09-23 8:34 crc32 for erasure code Loic Dachary @ 2013-09-23 16:59 ` Gregory Farnum 2013-09-23 17:10 ` Loic Dachary 0 siblings, 1 reply; 4+ messages in thread From: Gregory Farnum @ 2013-09-23 16:59 UTC (permalink / raw) To: Loic Dachary; +Cc: Ceph Development 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: crc32 for erasure code 2013-09-23 16:59 ` Gregory Farnum @ 2013-09-23 17:10 ` Loic Dachary 2013-09-23 17:14 ` Gregory Farnum 0 siblings, 1 reply; 4+ messages in thread From: Loic Dachary @ 2013-09-23 17:10 UTC (permalink / raw) To: Gregory Farnum; +Cc: Ceph Development [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: crc32 for erasure code 2013-09-23 17:10 ` Loic Dachary @ 2013-09-23 17:14 ` Gregory Farnum 0 siblings, 0 replies; 4+ messages in thread From: Gregory Farnum @ 2013-09-23 17:14 UTC (permalink / raw) To: Loic Dachary; +Cc: Ceph Development 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-09-23 17:14 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-23 8:34 crc32 for erasure code Loic Dachary 2013-09-23 16:59 ` Gregory Farnum 2013-09-23 17:10 ` Loic Dachary 2013-09-23 17:14 ` Gregory Farnum
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.