From owner-freebsd-cluster@FreeBSD.ORG Mon Apr 5 01:37:19 2004 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 001AA16A4CE for ; Mon, 5 Apr 2004 01:37:18 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9508343D48 for ; Mon, 5 Apr 2004 01:37:18 -0700 (PDT) (envelope-from sporner@nentec.de) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BAPbZ-0003tw-00; Mon, 05 Apr 2004 10:37:17 +0200 Received: from [194.25.215.66] (helo=gate.nentec.de) (TLSv1:EDH-RSA-DES-CBC3-SHA:168) (Exim 3.35 #1) id 1BAPbZ-0001sN-00; Mon, 05 Apr 2004 10:37:17 +0200 Received: from nenny.nentec.de (nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.11.3/) with ESMTP id i358bEq28955; Mon, 5 Apr 2004 10:37:14 +0200 Received: from nentec.de (andromeda.nentec.de [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3) with ESMTP id i358bDN24274; Mon, 5 Apr 2004 10:37:13 +0200 Message-ID: <40711AB9.6010602@nentec.de> Date: Mon, 05 Apr 2004 10:37:13 +0200 From: Andy Sporner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gabriel_ambuehl@buz.ch References: <002401c419e7$76692ac0$2f01a8c0@MICHAELIWZHLNY> <20040404103346.76151.qmail@web41501.mail.yahoo.com> <987274454.20040404124312@buz.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:56ea142331898a06f3703ddc80e12bc5 cc: freebsd-cluster@freebsd.org Subject: Re: Request for Cluster Recommendations X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 08:37:19 -0000 Gabriel Ambuehl wrote: >Sunday, April 4, 2004, 12:33:46 PM, you wrote: > > > >>As for the software, somebody else will have to >>speak up. I only work on HA (and later Mosix) type >>clustering for network application scalablity, >>rather than compute farms. >> >> > >IIRC the DragonflyBSD guys are working on Single System Image >clusters. But I doubt they are even anywhere near alpha stage at this >point. > >Oh and Andy, how about that frep thing of yours? Is it going anywhere? > > This is a news point. I had a rather nice suggestion from somebody "down under" that made sense and I wanted to get it in. At 20:00 (Berlin Standard time) I will release an initial release of FREP 2.0 Somebody pointed out that It was too bad I couldn't use 'triggers' to driver the replication. I realized that I had sort of that kind of thing already, but not generic enough for ordinary use outside of FREP. So now it is. For example, Whenever you modify /etc/inetd.conf the deaemon is sent a SIGHUP. Or if a file is created in a directory (such as a spool directory) that a program is called with the name of the file as an argument. This extended configuration also includes the original FREP stuff as an modular option. One can replace this module with a journal capture module as well. The modularity allows people to use the event triggers to be used without having to use FREP. FREP is then just an option as well as cluster locking of files (which will take a little longer--but the hooks are there). Sometime after this release there will be the actual tested FREP module as well to do the file replication. A "work in progress" version will be included for tonight. One of the main delays was that the kern_getcwd() functionality in 5.0 (and 5.2) is wholly unreliable. I had to incorporate a separate version to make it work correctly. Normally I hate such hacks, but it seems that the vfs_cache method that was used was not appearing to be 100% accurate (at least in the kernel). Many times when I would try to get a full filename I got errors (path component not a directory) when I passed a vnode of a file in to get the path name. In a file replication scheme--this is not acceptable.