All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Atchley, Scott" <atchleyes@ornl.gov>
To: Willem Jan Withagen <wjw@digiware.nl>
Cc: Chris Dunlop <chris@onthe.net.au>,
	Allen Samuels <Allen.Samuels@sandisk.com>,
	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: Thu, 7 Apr 2016 12:21:12 +0000	[thread overview]
Message-ID: <3E2B4A2A-04CA-45BB-9E45-C5A0EFA46A17@ornl.gov> (raw)
In-Reply-To: <57062DBC.5080105@digiware.nl>

> On Apr 7, 2016, at 2:51 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> 
> On 7-4-2016 04:59, Chris Dunlop wrote:
>> On Thu, Apr 07, 2016 at 12:52:48AM +0000, Allen Samuels wrote:
>>> So, what started this entire thread was Sage's suggestion that for HDD we
>>> would want to increase the size of the block under management. So if we
>>> assume something like a 32-bit checksum on a 128Kbyte block being read
>>> from 5ZB Then the odds become:
>>> 
>>> 1 - (2^-32 * (1-(10^-15))^(128 * 8 * 1024) - 2^-32 + 1) ^ ((5 * 8 * 10^21) / (4 * 8 * 1024))
>>> 
>>> Which is
>>> 
>>> 0.257715899051042299960931575773635333355380139960141052927
>>> 
>>> Which is 25%. A big jump ---> That's my point :)
>> 
>> Oops, you missed adjusting the second checksum term, it should be:
>> 
>> 1 - (2^-32 * (1-(10^-15))^(128 * 8 * 1024) - 2^-32 + 1) ^ ((5 * 8 * 10^21) / (128 * 8 * 1024))
>> = 0.009269991973796787500153031469968391191560327904558440721
>> 
>> ...which is different to the 4K block case starting at the 12th digit. I.e. not very different.
>> 
>> Which is my point! :)
> 
> Sorry for posting something this vague, but my memory (and Google) is playing games with me.
> 
> I have not so recently read some articles about this when I was studying ZFS which has a
> similar problem. Since it also aims for ZettaByte storage, and what I took from that discussion
> is that most of the CRC32 checksumtypes are susceptible to bit-error clustering. Which means that
> there is a bigger chance for a faulty block or set of error bits to go undetected.
> 
> Like I said, sorry for not being able to be more specific atm.
> 
> The ZFS preferred checksum is fletcher4, also because of its speed.
> But others include: fletcher2 | fletcher4 | sha256 | sha512 | skein | edonr
> 
> There is an article on Wikipedia that discusses Fletcher algorithms, strength and weakness:
> https://en.wikipedia.org/wiki/Fletcher's_checksum
> 
> —WjW

This ZFS blog has an interesting discussion of trusting (or not trusting) fletcher4:

https://blogs.oracle.com/bonwick/entry/zfs_dedup

Scott

  reply	other threads:[~2016-04-07 12:31 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 [this message]
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
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=3E2B4A2A-04CA-45BB-9E45-C5A0EFA46A17@ornl.gov \
    --to=atchleyes@ornl.gov \
    --cc=Allen.Samuels@sandisk.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=chris@onthe.net.au \
    --cc=ifedotov@mirantis.com \
    --cc=sage@newdream.net \
    --cc=wjw@digiware.nl \
    /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.