public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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