From owner-freebsd-cluster@FreeBSD.ORG Tue Feb 10 10:17:43 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 3BB0B16A4CF for ; Tue, 10 Feb 2004 10:17:43 -0800 (PST) Received: from web41503.mail.yahoo.com (web41503.mail.yahoo.com [66.218.93.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 327D043D2F for ; Tue, 10 Feb 2004 10:17:43 -0800 (PST) (envelope-from asporner@yahoo.com) Message-ID: <20040210181742.55466.qmail@web41503.mail.yahoo.com> Received: from [80.131.162.30] by web41503.mail.yahoo.com via HTTP; Tue, 10 Feb 2004 10:17:42 PST Date: Tue, 10 Feb 2004 10:17:42 -0800 (PST) From: Andy Sporner To: gabriel_ambuehl@buz.ch, Andy Sporner In-Reply-To: <349799726.20040210171004@buz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-cluster Subject: Re: Clustering with FreeBSD 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: Tue, 10 Feb 2004 18:17:43 -0000 Hi, > Is FREP avalaible somewhere? I'd love to bang on it. > Remote Raw > Devices would be cool, but if there's an easy way to > sync individual > files, that would do a good job too. The "Proof of concept" which is weak compare to the current version is available on my site at http://sporner.dyndns.org/bsdclusters/frep > > How does FREP figure out what files need to be > synced (walking the tree isn't exactly fast for big) > servers...)? That is clear. It is kind of a "throwback" to my Commodore Vic-20 days (no floppys! Tape! and 3K!) where you made a "wedge" when you wanted some kind of special behaviour. In this case I patched a couple of files (kern/vfs_syscalls, kern/vfs_vnops) whereby I watch for activities on files living in directories. Before each write operation I check to see if it is a "controlled" file and if so I secure a lock against it from the cluster monitor, meanwhile writer blocks until the grant (or it times out with a failure). When the write completes, it goes to the other node(s) and the lock is released. SO far I have been testing the concept without the locking and it is not too bad, but there are MANY opportunities for improvement (more assync for the UDP datagrams that are carrying the traffic). I really need to find out the performance of the locking, That is where I am really concerned. The Network Traffic be scaled with multiple links sending data (a feature from the clustering software) I feel that this is the right place to put the intercepts in the kernel. Otherwise with just a remote raw device you don't get over the filesystem cache problems. In this way it is handling the problem through the front door, rather than the back door. It has it's costs--that's clear, but I think the benefits are also clear. There are probably optimizations for the user-space code to delay certain activities and to "lease" locks for periods of time (that is already there but only rundimentarily). The available version the above links lack many things and is "NOT to be taken seriously" for high-end applications. There were some early testers and I got some very positive feedback (as with this time) and I have taken many of the suggestions in this version. In the next days I will put the "independant" version of the new FREP on my server. Same place (As the Germans say, "Same procedure this year--same procedure ever year" (a reference to "Dinner for One"). Look for this on Friday. The complete version I will put up some time later (as I have time to get it more or less working). Cheers Andy "S __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html