From: Justus Seifert <justus.seifert@dergleichrichter.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: drawbacks of non-ECC RAM
Date: Sat, 18 Jan 2014 01:52:49 +0100 [thread overview]
Message-ID: <52D9D061.1070100@dergleichrichter.de> (raw)
In-Reply-To: <pan$8d0bb$f4bae0c6$a4261ffd$c2bc88eb@cox.net>
[-- Attachment #1.1: Type: text/plain, Size: 1642 bytes --]
On 18.01.2014 00:18, Duncan wrote:
> valleysmail-lol5@yahoo.de posted on Fri, 17 Jan 2014 18:33:35 +0000 as
> excerpted:
>
>> I'd like to know if there are drawbacks in using btrfs with non-ECC RAM
>> instead of using ext4 with non-ECC RAM. I know that some features of
>> btrfs may rely on ECC RAM
>
> Crossed signals somewhere, as that's entirely incorrect. Btrfs does have
> date integrity checksumming as one of its features -- one which I'm using
> here BTW with raid1 mode so there's two copies of everything, on
> different devices, in case one goes bad -- but BTRFS IN NO WAY REQUIRES
> ECC RAM. ECC RAM is a hardware solution to a conceptually similar data
> integrity problem in memory to the problem btrfs addresses as filesystem
> software for non-volatile storage, but the two shouldn't be confused for
> each other or conflated at all -- they're entirely separate in practice,
> and one is hardware while the other is software.
To be fair: Both problems are essentially hardware problems where data
gets corrupted, but the solutions are different. ECC is only used in
systems where the additional cost for the hardware, energy (registered
ECC-RAM uses more electricity than register-less non-ECC-RAM), and space
(ECC-RAM is physically larger) is less than the cost of recovery in case
of soft errors caused by non-ECC-RAM. ECC-RAM does not offer a memory
performance advantage. See Wikipedia for more info about registered RAM
and ECC-RAM.
Raid1 uses more power and space as well, but also adds read performance.
So _there are reasons to use Raid1 besides resilience_.
> […]
[-- Attachment #1.2: justus_seifert.vcf --]
[-- Type: text/x-vcard, Size: 206 bytes --]
begin:vcard
fn:Justus Seifert
n:Seifert;Justus
adr:;;;Dresden;Saxony;;Germany
email;internet:justus.seifert@dergleichrichter.de
tel;cell:+4915730640509
x-mozilla-html:FALSE
version:2.1
end:vcard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2014-01-18 0:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 18:33 drawbacks of non-ECC RAM valleysmail-lol5
2014-01-17 20:40 ` Austin S Hemmelgarn
2014-01-17 23:18 ` Duncan
2014-01-18 0:52 ` Justus Seifert [this message]
2014-01-18 1:30 ` Fajar A. Nugraha
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=52D9D061.1070100@dergleichrichter.de \
--to=justus.seifert@dergleichrichter.de \
--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