From owner-freebsd-stable@FreeBSD.ORG Mon Jun 26 21:37:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 259CB16A402 for ; Mon, 26 Jun 2006 21:37:25 +0000 (UTC) (envelope-from M.Hirsch@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id B524543D6E for ; Mon, 26 Jun 2006 21:37:22 +0000 (GMT) (envelope-from M.Hirsch@gmx.de) Received: (qmail invoked by alias); 26 Jun 2006 21:37:21 -0000 Received: from HSI-KBW-085-216-025-126.hsi.kabelbw.de (EHLO [192.168.101.121]) [85.216.25.126] by mail.gmx.net (mp027) with SMTP; 26 Jun 2006 23:37:21 +0200 X-Authenticated: #820862 Message-ID: <44A0538E.6090906@gmx.de> Date: Mon, 26 Jun 2006 23:37:18 +0200 From: "M.Hirsch" User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> <20060626235355.Q95667@atlantis.atlantis.dp.ua> <44A04FD2.1030001@hirsch.it> <20060626212654.GB93703@freebie.xs4all.nl> In-Reply-To: <20060626212654.GB93703@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 21:37:25 -0000 Nope, I'd like my bank data to be stored on a system that does ECC, no question. But please, on hard disk level (RAID; that is _permanent_), not in the RAM of a single node. If memory gets corrupted, please, raise a kernel panic... Even if there's ECC in place. Counter question: Would you like your bank account data to be stored on a medium where one failure can be corrected, two can be detected, but three go unnoticed? How unlikely is that, if you've got some hardware that is really /broken/? I know this is a rather random thing to happen. Still, I think ECC memory is overrated. Better have it fail immediately. _With a kernel panic, please_ M. Wilko Bulte schrieb: >Balderdash. > >Following your rationale you want your bank account data >silently be corrupted by hardware with bit errors? Be my guest, give >me ECC any day. > >Proper hardware will log the ECC errors, a proper OS tailored to that >hardware will log and notify the sysadmins. > >That is how it should be done. > >Wilko > > >