All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Briggs <jbriggs@esoft.com>
To: Hans Reiser <reiser@namesys.com>
Cc: jfeise@ics.uci.edu, Toby Thain <toby@smartgames.ca>,
	reiserfs-list@namesys.com, vs <vs@thebsh.namesys.com>
Subject: Re: Reiser4 crash 2.6.16-mm1
Date: Tue, 28 Mar 2006 13:45:03 -0700	[thread overview]
Message-ID: <1143578704.2380.9.camel@localhost> (raw)
In-Reply-To: <442997D9.7000505@namesys.com>

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

On Tue, 2006-03-28 at 12:08 -0800, Hans Reiser wrote:
> Jonathan Briggs wrote:
[...]
> >And if it's a production machine, it is using ECC RAM, I would hope.  If
> >it is, memory problems (unreported ones, anyway) are very, very
> >unlikely.
> >  
> >
> Jonathan, be merciful, ECC ram last I checked is twice the cost of
> regular and the mobs cost more too.  (I am sure the cost to produce is <
> 15% more, which makes it a great pity Intel does not standardize on
> requiring it and force it to be cheap)  Some folks need to save money. 
> Yeah, I know, this time it may have cost him more in cost of his time
> but we are all just assuming it is memory.  Unfortunately, unless he
> checks it or we see an identical error message from another user with
> checked memory, or vs tells me he sees a flaw in the code, we need to
> assume it is memory.
[...]

Yes, I know. :)

But for a production machine that is "producing" something of value, the
extra cost should not be an issue.  RAM errors are so subtle and so hard
to find that ECC is of far more value than RAID.  It is obvious when
your disk fails.

An extra high bit in a credit transaction could cost you $16,384 and you
might not ever realize what happened. :)

Anyway, off topic, but ECC is highly recommended.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

  reply	other threads:[~2006-03-28 20:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-27 21:41 Reiser4 crash 2.6.16-mm1 Joe Feise
2006-03-27 21:58 ` Toby Thain
2006-03-27 22:32   ` Joe Feise
2006-03-28  4:39     ` Valdis.Kletnieks
2006-03-28  6:34       ` Toby Thain
2006-03-28 15:34         ` Joachim Feise
2006-03-28 16:49           ` Toby Thain
2006-03-28 19:18           ` Jonathan Briggs
2006-03-28 20:08             ` Hans Reiser
2006-03-28 20:45               ` Jonathan Briggs [this message]
2006-03-28 21:22                 ` Gregory Maxwell
2006-03-28 21:56                   ` Joe Feise
2006-03-28 20:54               ` Joe Feise
2006-03-28 21:52                 ` Sergey Ivanov
2006-03-28 22:03                   ` Joe Feise
2006-03-28 20:50             ` Joe Feise
2006-03-28 21:04               ` Hans Reiser
2006-03-28  3:47 ` Joe Feise

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=1143578704.2380.9.camel@localhost \
    --to=jbriggs@esoft.com \
    --cc=jfeise@ics.uci.edu \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=toby@smartgames.ca \
    --cc=vs@thebsh.namesys.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.