From: George Mitchell <george@chinilu.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs and ECC RAM
Date: Mon, 20 Jan 2014 08:08:19 -0800 [thread overview]
Message-ID: <52DD49F3.8050100@chinilu.com> (raw)
In-Reply-To: <52DD426A.5020104@shiftmail.org>
After reading the recent posts on this topic I am beginning to think
there is some real confusion between "check sums" and "parity". These
are two different things which serve two different purposes. In each
case, bad RAM would have different repercussions. But I still fail to
see how, in the case of either btrfs or zfs, bad RAM could damage data
via the checksum process. In fact, I would expect that checksum would
guard against that very thing. If not, checksum is very badly
implemented. Most of the world uses non-ECC RAM. I simply cannot
believe that a file system like zfs would expose the user to more risk
than ext4. I think there is some very inappropriate panic going on over
this thing. Just because one source has asserted that something like
this can happen does not make it fact. As it concerns zfs, it needs to
be brought up at a zfs forum, not here. As it concerns btrfs, I think
it has been made clear by some of the sharpest contributors here that
this is not going to pose any risk with btrfs. If a btrfs checksum
fails, btrfs is not going to change anything if it cannot find a copy
that passes checksum, and bad RAM is not going to cause bad data to pass
checksum. But I CAN see how bad RAM could affect parity calculations
and resulting data IN THE ABSENCE of protective checksums and cannot
help but wonder if THAT is what the original article is describing.
next prev parent reply other threads:[~2014-01-20 16:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-18 0:23 btrfs and ECC RAM Ian Hinder
2014-01-18 0:49 ` cwillu
2014-01-18 1:10 ` George Mitchell
2014-01-18 7:16 ` Duncan
2014-01-19 19:02 ` Martin Steigerwald
2014-01-19 20:20 ` George Mitchell
2014-01-19 20:54 ` Duncan
2014-01-24 23:57 ` Russell Coker
2014-01-25 4:34 ` Duncan
2014-01-19 21:32 ` Duncan
2014-01-20 0:17 ` George Eleftheriou
2014-01-20 3:13 ` Austin S Hemmelgarn
2014-01-20 14:57 ` Ian Hinder
2014-01-20 15:36 ` Bob Marley
2014-01-20 16:04 ` Austin S Hemmelgarn
2014-01-20 16:08 ` George Mitchell [this message]
2014-01-25 0:45 ` Chris Murphy
2014-01-27 16:08 ` Calvin Walton
2014-01-27 16:42 ` Chris Murphy
2014-01-20 16:13 ` Duncan
2014-01-20 15:55 ` Fajar A. Nugraha
2014-01-23 16:00 ` David Sterba
-- strict thread matches above, loose matches on Subject: below --
2014-01-20 15:27 Ian Hinder
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=52DD49F3.8050100@chinilu.com \
--to=george@chinilu.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox