From owner-freebsd-stable@FreeBSD.ORG  Mon May 22 06:48:59 2006
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 39D3516A42F
	for <freebsd-stable@freebsd.org>; Mon, 22 May 2006 06:48:59 +0000 (UTC)
	(envelope-from bc979@lafn.org)
Received: from zoot.lafn.org (zoot.lafn.ORG [206.117.18.6])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B994043D46
	for <freebsd-stable@freebsd.org>; Mon, 22 May 2006 06:48:58 +0000 (GMT)
	(envelope-from bc979@lafn.org)
Received: from [10.0.1.5] (pool-71-109-244-179.lsanca.dsl-w.verizon.net
	[71.109.244.179]) (authenticated bits=0)
	by zoot.lafn.org (8.13.4/8.13.4) with ESMTP id k4M6mqPx036982
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Sun, 21 May 2006 23:48:53 -0700 (PDT) (envelope-from bc979@lafn.org)
In-Reply-To: <44714F23.6000504@datalinktech.com.au>
References: <4471361B.5060208@freebsd.org>
	<66DF01E1-277C-42EE-896E-1E7F4C2ABDDE@lafn.org>
	<44714F23.6000504@datalinktech.com.au>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2CBCDBD0-CC9F-4B9A-BC79-9F248DFE7A3F@lafn.org>
Content-Transfer-Encoding: 7bit
From: Doug Hardie <bc979@lafn.org>
Date: Sun, 21 May 2006 23:48:51 -0700
To: David Nugent <davidn@datalinktech.com.au>
X-Mailer: Apple Mail (2.750)
X-Virus-Scanned: ClamAV 0.88/1475/Sun May 21 22:09:26 2006 on zoot.lafn.org
X-Virus-Status: Clean
Cc: freebsd-stable@freebsd.org
Subject: Re: FreeBSD Security Survey
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2006 06:48:59 -0000


On May 21, 2006, at 22:41, David Nugent wrote:

> A good failover strategy comes into play here.
>
> If you have one, then taking a single production machine off-line  
> for a short period should be no big deal, even routine, and should  
> not even be noticed by users if done correctly.  This should be  
> planned for and part of the network/system design. Yes, it  
> definitely requires more resources to support, but I'll rephrase  
> the same problem: what happens when (and I mean *when* and not  
> *if*) a motherboard or network card fries or you suffer a hard disk  
> crash (even 2+ drives failing at the same time on a raid array is  
> not particularly unusual considering that drives are quite often  
> from the same manufactured batch)?
>
> Lack of a failover on mission critical systems that *can't* be  
> offline is like playing russian roulette.

Failover sounds good in theory but has significant issues in practice  
that make it sometimes worse than the alternative.  Take mail  
spools.  If you failover, mail the user saw before has disappeared.   
Then when you "fail back" it reappears and newer messages disappear.   
This is hardly unnoticable.  My users do not find that at all  
acceptable.  Putting the mail spools on a different machine just  
moves that problem to the different machine.  Trying to keep multiple  
spools consistent has problems also.  I have watched raid system lose  
their data too.  A nice power spike - 1.5Kv from a lightning strike  
in the local area will do it.