public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs and ECC RAM
Date: Sat, 25 Jan 2014 04:34:14 +0000 (UTC)	[thread overview]
Message-ID: <pan$e5673$29a4d4ab$eacdefea$4b2cc29f@cox.net> (raw)
In-Reply-To: 126421479.FuRWa26fOs@russell.coker.com.au

Russell Coker posted on Sat, 25 Jan 2014 10:57:43 +1100 as excerpted:

> On Sun, 19 Jan 2014 12:20:22 George Mitchell wrote:
>> I can easily imagine btrfs taking a system down due to memory error,
>> but not btrfs causing data corruption due to a memory error.
> 
> I had a system which had apparently worked OK on Ext4 but had some
> memory errors.  After twice having a serious BTRFS corruption (needed
> backup-format- restore) I ran memtest and found that a DIMM was broken.
> 
> In that sort of situation it seems that BTRFS is likely to be more
> fragile due to the more complex data structures and due to the fact that
> it's a newer filesystem with less corner cases handled.

I believe that was his point (as it has been mine, elsewhere).  If there 
are memory errors, btrfs might well "take down the system", or as you 
mention, corrupt the btrfs such that it needs blown away with a mkfs and 
restore from backup, but it should NOT invisibly corrupt the data.  If 
the data is available, it should be correct as it was stored, memory 
issue or no memory issue, ECC DRAM or non-ECC DRAM.  (Tho there's a small 
chance that the data was corrupted in memory before it was stored, but 
that's the case no matter the filesystem, as the filesystem has nothing 
to do with it then.)

IOW, btrfs is binary.  The data is either there and valid, or its not 
there, period.  There's no there but not valid case -- btrfs simply won't 
serve the data period if it's invalid and there's no valid copy available 
to substitute for it.

And yes, that does make btrfs more brittle on defective equipment, 
because it'll break all the way much more frequently than filesystems 
that would instead serve only slightly invalid data, without knowing how 
valid it is because they don't do the checks btrfs does.

*CAVEAT!  This assumes the filesystem isn't mounted with nodatacow/
nodatasum, and that we're not talking about files with the NOCOW extended 
attribute set, thus specific-case disabling these important features of 
btrfs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2014-01-25  4:34 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 [this message]
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
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='pan$e5673$29a4d4ab$eacdefea$4b2cc29f@cox.net' \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox