From: Allen Samuels <Allen.Samuels@sandisk.com>
To: Dan van der Ster <dan@vanderster.com>
Cc: Chris Dunlop <chris@onthe.net.au>, Sage Weil <sage@newdream.net>,
Igor Fedotov <ifedotov@mirantis.com>,
ceph-devel <ceph-devel@vger.kernel.org>
Subject: RE: Adding compression/checksum support for bluestore.
Date: Tue, 5 Apr 2016 20:50:27 +0000 [thread overview]
Message-ID: <CY1PR0201MB1897166E1328EF7895DD8136E89E0@CY1PR0201MB1897.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CABZ+qqkEMrWeQvgYC7eTsXvZY5zECaV7VC0nNiK8BfSSzfU+RQ@mail.gmail.com>
If messenger is doing CRC-32, then it's probably not yielding as much value as you would like. That's because the NIC has ALREADY done a CRC-32 on data over the wire. Doing the extra CRC in software will certainly help verify that the NIC, PCIe bus, DRAM system is working well -- but the real value is an end-to-end integrity check of the software (i.e., most likely failure is a software failure). You don't need a CRC for that. However, CRC is cheap enough not to worry.
As for scrub, it's different -- presumably you're already downstream of the HW ECC and whatever strong checksums you put on BlueStore. Totally different discussion. Plus, many of the "failure" modes here aren't actual failures. In other words some of the failures don't deliver corrupt data, they just rebuild data that was already good :)
Allen Samuels
Software Architect, Fellow, Systems and Software Solutions
2880 Junction Avenue, San Jose, CA 95134
T: +1 408 801 7030| M: +1 408 780 6416
allen.samuels@SanDisk.com
> -----Original Message-----
> From: Dan van der Ster [mailto:dan@vanderster.com]
> Sent: Tuesday, April 05, 2016 5:58 AM
> To: Allen Samuels <Allen.Samuels@sandisk.com>
> Cc: Chris Dunlop <chris@onthe.net.au>; Sage Weil <sage@newdream.net>;
> Igor Fedotov <ifedotov@mirantis.com>; ceph-devel <ceph-
> devel@vger.kernel.org>
> Subject: Re: Adding compression/checksum support for bluestore.
>
> On Tue, Apr 5, 2016 at 1:58 AM, Allen Samuels
> <Allen.Samuels@sandisk.com> wrote:
> > It's now clear that if you double the data size, you need to add one bit to
> your checksum to compensate.
>
> Slight parenthesis: let's not forget that the messenger and OSD deep scrubs
> use crc32c for potentially very large chunks of data. If bluestore gets strong
> checksums we should try be consistent throughout the code base.
>
> --
> Dan
next prev parent reply other threads:[~2016-04-05 20:50 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 19:46 Adding compression/checksum support for bluestore Allen Samuels
2016-03-30 20:41 ` Vikas Sinha-SSI
2016-03-30 22:24 ` Sage Weil
2016-03-30 22:35 ` Allen Samuels
2016-03-31 16:31 ` Igor Fedotov
2016-03-30 22:15 ` Sage Weil
2016-03-30 22:22 ` Gregory Farnum
2016-03-30 22:30 ` Sage Weil
2016-03-30 22:43 ` Allen Samuels
2016-03-30 22:32 ` Allen Samuels
2016-03-30 22:52 ` Allen Samuels
2016-03-30 22:57 ` Sage Weil
2016-03-30 23:03 ` Gregory Farnum
2016-03-30 23:08 ` Allen Samuels
2016-03-31 23:02 ` Milosz Tanski
2016-04-01 3:56 ` Chris Dunlop
2016-04-01 4:56 ` Sage Weil
2016-04-01 5:28 ` Chris Dunlop
2016-04-01 14:58 ` Sage Weil
2016-04-01 19:49 ` Chris Dunlop
2016-04-01 23:08 ` Allen Samuels
2016-04-02 2:23 ` Allen Samuels
2016-04-02 2:51 ` Gregory Farnum
2016-04-02 5:05 ` Chris Dunlop
2016-04-02 5:48 ` Allen Samuels
2016-04-02 6:18 ` Gregory Farnum
2016-04-03 13:27 ` Sage Weil
2016-04-04 15:33 ` Chris Dunlop
2016-04-04 15:51 ` Chris Dunlop
2016-04-04 17:58 ` Allen Samuels
2016-04-04 15:26 ` Chris Dunlop
2016-04-04 17:56 ` Allen Samuels
2016-04-02 5:08 ` Allen Samuels
2016-04-02 4:07 ` Chris Dunlop
2016-04-02 5:38 ` Allen Samuels
2016-04-04 15:00 ` Chris Dunlop
2016-04-04 23:58 ` Allen Samuels
2016-04-05 12:35 ` Sage Weil
2016-04-05 15:10 ` Chris Dunlop
2016-04-06 6:38 ` Chris Dunlop
2016-04-06 15:47 ` Allen Samuels
2016-04-06 17:17 ` Chris Dunlop
2016-04-06 18:06 ` Allen Samuels
2016-04-07 0:43 ` Chris Dunlop
2016-04-07 0:52 ` Allen Samuels
2016-04-07 2:59 ` Chris Dunlop
2016-04-07 9:51 ` Willem Jan Withagen
2016-04-07 12:21 ` Atchley, Scott
2016-04-07 15:01 ` Willem Jan Withagen
2016-04-07 9:51 ` Chris Dunlop
2016-04-08 23:16 ` Allen Samuels
2016-04-05 20:41 ` Allen Samuels
2016-04-05 21:14 ` Sage Weil
2016-04-05 12:57 ` Dan van der Ster
2016-04-05 20:50 ` Allen Samuels [this message]
2016-04-06 7:15 ` Dan van der Ster
2016-03-31 16:27 ` Igor Fedotov
2016-03-31 16:32 ` Allen Samuels
2016-03-31 17:18 ` Igor Fedotov
2016-03-31 17:39 ` Piotr.Dalek
2016-03-31 18:44 ` Allen Samuels
2016-03-31 16:58 ` Igor Fedotov
2016-03-31 18:38 ` Allen Samuels
2016-04-04 12:14 ` Igor Fedotov
2016-04-04 14:44 ` Allen Samuels
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=CY1PR0201MB1897166E1328EF7895DD8136E89E0@CY1PR0201MB1897.namprd02.prod.outlook.com \
--to=allen.samuels@sandisk.com \
--cc=ceph-devel@vger.kernel.org \
--cc=chris@onthe.net.au \
--cc=dan@vanderster.com \
--cc=ifedotov@mirantis.com \
--cc=sage@newdream.net \
/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.