From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs and ECC RAM
Date: Sun, 19 Jan 2014 21:32:21 +0000 (UTC) [thread overview]
Message-ID: <pan$ab6b4$b10b0e35$6a4b5887$44030d49@cox.net> (raw)
In-Reply-To: 1420240.1BEopi7BrR@merkaba
Martin Steigerwald posted on Sun, 19 Jan 2014 20:02:41 +0100 as excerpted:
> I´d probably like if all computers had ECC RAM, but then I heard more
> than once that ECC doesn´t even detect all possible memory errors.
Heh, don't I know it! I had an original generation dual socket, 3-digit
AMD Opteron system for many years (it finally bit the dust, bulging/
exploded capacitors, a bit over a year ago). As all Opterons of that era
it took registered/ecc RAM, but for a couple years I was running PC3200
rated RAM that Just. Couldn't'. Quite. Stably. Take. its clock-rating.
At some point a BIOS upgrade gave me the ability to de-clock it slightly,
and then it was "stable as stone", even with wait-cycles decreased a bit
to partially make up for the lower clocking. And later I upgraded memory
and the new memory was fine at rated clock.
But it took me a long time to figure out what was wrong, because I
couldn't imagine it was the memory due to the ECC, and memtest86+ passed
it with flying colors as well. But I guess memtest86+ checks memory cell
stability but not really clock sensitivity (data in transit on the memory
bus), and clock sensitivity is where the problem was.
Interestingly enough, one of the more common failures was when untarring
a tarball. Apparently that's checksummed, and every once in awhile it
would fail that checksum. At least that failure, unlike some of the
other fortunately less frequent problems, was user-space-only and
recoverable by simply running the untar once again.
What amazed me, however, was how thru all that reiserfs was stable as a
rock. Well, after data=ordered mode was introduced and became the
default, anyway. Before that, not so much. =:^\
--
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
next prev parent reply other threads:[~2014-01-19 21:32 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 [this message]
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$ab6b4$b10b0e35$6a4b5887$44030d49@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