From owner-freebsd-stable@FreeBSD.ORG Mon Jun 26 22:22:57 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 2C95C16A401 for ; Mon, 26 Jun 2006 22:22:57 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E8D44752 for ; Mon, 26 Jun 2006 22:22:56 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5QMMloH072470; Tue, 27 Jun 2006 01:22:47 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 27 Jun 2006 01:22:47 +0300 (EEST) From: Dmitry Pryanishnikov To: "M.Hirsch" In-Reply-To: <44A04FD2.1030001@hirsch.it> Message-ID: <20060627011512.N95667@atlantis.atlantis.dp.ua> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 22:22:57 -0000 Hello! On Mon, 26 Jun 2006, M.Hirsch wrote: > ECC is a way to mask broken hardware. I rather have my hardware fail directly > when it does first, so I can replace it _immediately_ You got it backwards. If your data has any value to you, then you don't want to miss any single-error bit in it, do you? If you're running hardware w/o ECC, your single-bit error in your data will go to the disk unnoticed, and you'll lose your data. With ECC, hardware will correct it. In (rare) case of multiple-bit error ECC logic will generate NMI for you, so you'll notice and "replace it _immediately_" instead of two weeks ago when your archive wont extract. > What's your hardware good for if it passes a "test", but fails in production? It's the way in what RAM will manifest single-bit errors: you run memory test - it won't catch them, later in production you'll miss this error because nothing will provide extra sanity check of your data. > ECC is totally overrated. Only by the people who don't understand it's point! Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE