From owner-freebsd-geom@FreeBSD.ORG Fri Dec 16 14:51:20 2005 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F7FC16A41F for ; Fri, 16 Dec 2005 14:51:20 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE3F343D5A for ; Fri, 16 Dec 2005 14:51:09 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by nproxy.gmail.com with SMTP id p48so232049nfa for ; Fri, 16 Dec 2005 06:51:08 -0800 (PST) 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=VKk0s1Jpvv0VX4PDJzgQN0oWMJZyEeM5W/ozRdDpsEddDMhyOeZGikZETcOPdjcwtl6sZf/kEcDjwWJB9qcgm6gVmro2NxkVqvlMS2j2nwyX/f6WKanA0NfqqVUIFjE+CjHZ/VjIZVFwAw9b5UsRttGLCljcj47QLiRGX8fVvi0= Received: by 10.48.249.2 with SMTP id w2mr140442nfh; Fri, 16 Dec 2005 06:51:07 -0800 (PST) Received: by 10.48.240.11 with HTTP; Fri, 16 Dec 2005 06:51:07 -0800 (PST) Message-ID: <1dbad3150512160651nc440efer@mail.gmail.com> Date: Fri, 16 Dec 2005 15:51:07 +0100 From: Michael Schuh To: Eric Anderson In-Reply-To: <1dbad3150512160537y4a944f81u@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1dbad3150512090509l2ab08e03k@mail.gmail.com> <43998C95.3050505@fer.hr> <1dbad3150512130421i5278d693g@mail.gmail.com> <439ED00E.7050701@centtech.com> <1dbad3150512150355r576b1b0j@mail.gmail.com> <43A18CAB.6020705@centtech.com> <1dbad3150512160537y4a944f81u@mail.gmail.com> Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Questions about geom-gate and RAID1/10 and CARP X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2005 14:51:20 -0000 Hello Eric, Hello List, 2005/12/16, Michael Schuh : > > There are others, like lustre, gfs, polyserve, etc, however none of the= m > > work in FreeBSD at this point. A few people (including myself) have > > started a project to port gfs to FreeBSD (gfs4fbsd project on > > sourceforge). > Oh i think this was a very good idea......i'm will watch this project. > another good thing was gpfs from IBM....... > > > > > > > > I'm wondering actually if you couldn't actually do this with NFS, and > > hacking some pieces together. Haven't thought through it, but seems > > like maybe you could make the active writer an nfs server, that also > > mounts it's own nfs share rw, but the nfs sharing would be on a virtual > > interface, or at least the one that 'moves' with your failover. The > > other machines would mount that nfs server's export ro, and when it > > fails over, the one taking over would have to run a script to begin > > serving that export rw to all, and it's own client would continue its > > connection but now on it's new virtual interface. You'd also have to > > have the ggate stuff set up, so that it was mirroring the original > > 'master' disk, but when the failover occurred, you would quickly mount > > your local mirrored disk rw, ignoring the 'unclean' message, begin a > > background fsck, then start the nfs server on that mount point. You > > would probably also have to fail the original drive in the mirror to > > effectively 'fence' that node from making disk changes at the same time > > the new master did. I have made a quick lookup into the coda-doc's and it seems to me, that coda is exactly the solution for this Problem, but im not really sure. i do further reading the doc's of coda....... > > Oh yes, this was also possible, but i would slunk around the script/cron-= hell. > It wasn't really a hell, but a serious error source..... > my prior idea was to mount union two different mounted nfs-servers..... > like your suggestion, but here comes the next problem......unionfs.... > and later the sync....... > > I hope a good solution for real HA is around the corner.... > > michael > Thanks to all regards michael