From owner-freebsd-stable@FreeBSD.ORG Tue Apr 11 19:16:50 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 BC72B16A401 for ; Tue, 11 Apr 2006 19:16:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF92D43D66 for ; Tue, 11 Apr 2006 19:16:08 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail02.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k3BJG65p004695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Apr 2006 05:16:07 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k3BJG6Ze002288; Wed, 12 Apr 2006 05:16:06 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k3BJG6E6002287; Wed, 12 Apr 2006 05:16:06 +1000 (EST) (envelope-from peter) Date: Wed, 12 Apr 2006 05:16:05 +1000 From: Peter Jeremy To: Michael Schuh Message-ID: <20060411191605.GA740@turion.vk2pj.dyndns.org> References: <1dbad3150604070754m6702e6acw2175c306504f3c13@mail.gmail.com> <4436A2B4.4010608@mac.com> <1dbad3150604100511v6a0d27a9kb38920ee280dab2c@mail.gmail.com> <20060410185035.GC739@turion.vk2pj.dyndns.org> <1dbad3150604110415h2941769ahcd014548f8ed8b77@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1dbad3150604110415h2941769ahcd014548f8ed8b77@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-stable@freebsd.org Subject: Re: Needs suggestion for redundant Storage 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: Tue, 11 Apr 2006 19:16:50 -0000 On Tue, 2006-Apr-11 13:15:48 +0200, Michael Schuh wrote: >> You probably can't replace defective hardware so fast that the users >> don't notice. They will probably also notice when a system crash >> garbles the filesystem. > >that was the reason why i would make a mirrored system with CARP >and ggated....... CARP can let you failover an IP address and ggated provides remote access to a physical disk device but the combination will not give you a fault tolerant server. One major problem is that you will lose the content of the cache when a system fails - this amounts to roughly the last 30 seconds of data written (though the write-through behaviour of NFS may mitigate this). Other potential problems are: Loss of connection state - NFS is stateless but lockd and mountd retain client state information so you will lose any client locks and the server may object to being presented with filehandles that were issued by a different host. Handling the failure of the inactive host - you will need to identify the behaviour when the remote part of your mirror becomes inaccessible. And none of the above protects against filesystem corruption. Cheap hardware presumably means that you won't be using ECC RAM and there will me minimal (if any) protection against data corruption on the various busses. The odd bit-flip will be virtually undetectable until someone notices that their data is corrupt. >> Based on your comments of low cost and massive size, I presume you >> can't afford a proper backup solution either. This is a recipe for >> disaster if the data is valuable. >yes, i can't backup this amount of data at this moment, but this was >not the focus...yet Without backups, you can't recover from any problems - user errors or system errors. I'm certain the lack of backups _will_ become the focus as soon as something valuable is lost. And given the sort of dodgy setup you want to construct, that may not take long. >> Read the mailing lists - they are full of problems with them. If >> you value your data you will not use Sil controller. >> >yes, this do i also know, but if i have a lot of them, and 2 falls out, >so what happens if i had another box with my data? The data is just as likely to be garbled on the remote system as well. I don't think people are saying that the Sil controllers stop working, they just don't work reliably so you can't rely on any data that has been handled by a Sil controller. >Oh that was fist not my idea, the management has questioned these features, >in have said "OMG you aore not serious", but is it...... :-(( >so that is better for me and my job to make what management wishes, >later i can say.....i have you warned...... You need to write a memo to your management that clearly points out the risks. Keep a notarised copy for yourself and make sure yout CV is up to date. You can rest assured that you will be the scaegoat when it all goes wrong. -- Peter Jeremy