From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Expected behavior of bad sectors on one drive in a RAID1
Date: Wed, 21 Oct 2015 08:07:46 -0400 [thread overview]
Message-ID: <56278012.2060206@gmail.com> (raw)
In-Reply-To: <56277C4A.70300@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On 2015-10-21 07:51, Austin S Hemmelgarn wrote:
> On 2015-10-20 15:59, Austin S Hemmelgarn wrote:
>> On 2015-10-20 15:20, Duncan wrote:
>>> Yes, there's some small but not infinitesimal chance the checksum may be
>>> wrong, but if there's two copies of the data and the checksum on one is
>>> wrong while the checksum on the other verifies... yes, there's still
>>> that
>>> small chance that the one that verifies is wrong too, but that it's any
>>> worse than the one that does not verify? /That's/ getting close to
>>> infinitesimal, or at least close enough for the purposes of a mailing-
>>> list claim without links to supporting evidence by someone who has
>>> already characterized it as not mathematically rigorous... and for me,
>>> personally. I'm not spending any serious time thinking about getting
>>> hit
>>> by lightening, either, tho by the same token I don't go out flying kites
>>> or waving long metal rods around in lightning storms, either.
>> With a 32-bit checksum and a 4k block (the math is easier with smaller
>> numbers), that's 4128 bits, which means that a random single bit error
>> will have a approximately 0.24% chance of occurring in a given bit,
>> which translates to an approximately 7.75% chance that it will occur in
>> one of the checksum bits. For a 16k block it's smaller of course
>> (around 1.8% I think, but that's just a guess), but it's still
>> sufficiently statistically likely that it should be considered.
> As mentioned in my other reply to this, I did the math wrong (bit of a
> difference between kilobit and kilobyte)
And I realize of course right after sending this that my other reply
didn't get through because GMail refuses to send mail in plain text, no
matter how hard I beat it over the head...
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-10-21 12:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 4:16 Expected behavior of bad sectors on one drive in a RAID1 james harvey
2015-10-20 4:45 ` Russell Coker
2015-10-20 13:00 ` Austin S Hemmelgarn
2015-10-20 13:15 ` Russell Coker
2015-10-20 13:59 ` Austin S Hemmelgarn
2015-10-20 19:20 ` Duncan
2015-10-20 19:59 ` Austin S Hemmelgarn
2015-10-20 20:54 ` Tim Walberg
2015-10-21 11:51 ` Austin S Hemmelgarn
2015-10-21 12:07 ` Austin S Hemmelgarn [this message]
2015-10-21 16:01 ` Chris Murphy
2015-10-21 17:28 ` Austin S Hemmelgarn
2015-10-20 18:54 ` Duncan
2015-10-20 19:48 ` Austin S Hemmelgarn
2015-10-20 21:24 ` Duncan
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=56278012.2060206@gmail.com \
--to=ahferroin7@gmail.com \
--cc=1i5t5.duncan@cox.net \
--cc=linux-btrfs@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.