From: George Mitchell <george@chinilu.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs and ECC RAM
Date: Fri, 17 Jan 2014 17:10:17 -0800 [thread overview]
Message-ID: <52D9D479.5040809@chinilu.com> (raw)
In-Reply-To: <AE93F05D-BEE7-4CE6-970E-137EA41D1C7B@aei.mpg.de>
On 01/17/2014 04:23 PM, Ian Hinder wrote:
> Hi,
>
> I have been reading a lot of articles online about the dangers of using ZFS with non-ECC RAM. Specifically, the fact that when good data is read from disk and compared with its checksum, a RAM error can cause the read data to be incorrect, causing a checksum failure, and the bad data might now be written back to the disk in an attempt to correct it, corrupting it in the process. This would be exacerbated by a scrub, which could run through all your data and potentially corrupt it. There is a strong current of opinion that using ZFS without ECC RAM is "suicide for your data".
>
> I have been unable to find any discussion of the extent to which this is true for btrfs. Does btrfs handle checksum errors in the same way as ZFS, or does it perform additional checks before writing "corrected" data back to disk? For example, if it detects a checksum error, it could read the data again to a different memory location to determine if the error existed in the disk copy or the memory.
>
> >From what I've been reading, it sounds like ZFS should not be used with non-ECC RAM. This is reasonable, as ZFS' resource requirements mean that you probably only want to run it on server-grade hardware anyway. But with btrfs eventually being the default filesystem for Linux, that would mean that all linux machines, even cheap consumer-grade hardware, would need ECC RAM, or forego many of the advantages of btrfs.
>
> What is the situation?
>
This subject is already being discussed on this list under the title of
"drawbacks of non-ECC RAM". So I suggest you follow that thread back
and THEN come back with any further questions.
next prev parent reply other threads:[~2014-01-18 1:09 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 [this message]
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
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=52D9D479.5040809@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