From owner-freebsd-stable@FreeBSD.ORG Wed Apr 12 11:24:13 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 7655E16A406 for ; Wed, 12 Apr 2006 11:24:13 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E6F743D46 for ; Wed, 12 Apr 2006 11:24:12 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so1022115wxc for ; Wed, 12 Apr 2006 04:24:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NQs7HhpbiuCvT2Ef/FAh/WQuC/QbT9hGshW+1rebNk870nIjjHGscqB69gR7eFB5jVoDY6U8QNI0yJ7hikGplBAWgE477pvuvubG5JxXcdLXb0MDzVs2PWc6XVV5+CJIHhEt03y96yF51vNEiK9XXcyyqXuLBJTeiwL6kkvHdBc= Received: by 10.70.27.2 with SMTP id a2mr1320173wxa; Wed, 12 Apr 2006 04:24:11 -0700 (PDT) Received: by 10.70.112.16 with HTTP; Wed, 12 Apr 2006 04:24:11 -0700 (PDT) Message-ID: <1dbad3150604120424v808c33dkef3a46d165677b8b@mail.gmail.com> Date: Wed, 12 Apr 2006 13:24:11 +0200 From: "Michael Schuh" To: "Peter Jeremy" In-Reply-To: <20060411191605.GA740@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1dbad3150604070754m6702e6acw2175c306504f3c13@mail.gmail.com> <4436A2B4.4010608@mac.com> <1dbad3150604100511v6a0d27a9kb38920ee280dab2c@mail.gmail.com> <20060410185035.GC739@turion.vk2pj.dyndns.org> <1dbad3150604110415h2941769ahcd014548f8ed8b77@mail.gmail.com> <20060411191605.GA740@turion.vk2pj.dyndns.org> 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: Wed, 12 Apr 2006 11:24:13 -0000 > 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. Yes, i agree, that was the reason why i would use ggated whit carp and geom mirror, but the problem was the mount of the shared filesystem.... carp..if the machine or the netif goes to hell ggated to mirror the shared disks over the network with gmirror if one disk fails gmirror noticed that and let me show them.... > > 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. i agree also with them....but i can not have all the things another solution to prevent that was an cluster-tool that mirrors files not filesystems over the net.... may be i should make a try or think over another solution... > 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. > yes i know, and i be not there friend, backup is my friend by any problem w= ith the boxes....but this comes later if the money is there :-) or the management will spend the money.... > >> 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 featur= es, > >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. *grin* that was also an good idea, the first disagreement i have made past days...the next follows if the etat-management begins..... i would sort the costs for possibiliy disaster recovery in relativiness of costs of data-corruption (in the cas all data goes to hell).... i think then comes the right thinking back..... i think the best question for that to the management was: "what if the data goes to /dev/null by any failure fo the Hardware, and keep in mind, we do not have any backup." regars michael