From owner-freebsd-cluster@FreeBSD.ORG Tue Feb 10 10:32:26 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 E570616A4CE for ; Tue, 10 Feb 2004 10:32:26 -0800 (PST) Received: from iota.root-servers.ch (iota.root-servers.ch [193.41.193.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 159BB43D1D for ; Tue, 10 Feb 2004 10:32:26 -0800 (PST) (envelope-from gabriel_ambuehl@buz.ch) Received: (qmail 65554 invoked from network); 10 Feb 2004 18:32:23 -0000 Received: from 217-162-134-28.dclient.hispeed.ch (HELO ga) (217.162.134.28) by 0 with SMTP; 10 Feb 2004 18:32:23 -0000 Date: Tue, 10 Feb 2004 19:33:15 +0100 From: Gabriel Ambuehl Organization: BUZ Internet Services X-Priority: 3 (Normal) Message-ID: <444282470.20040210193315@buz.ch> To: Andy Sporner In-Reply-To: <20040210181742.55466.qmail@web41503.mail.yahoo.com> References: <349799726.20040210171004@buz.ch> <20040210181742.55466.qmail@web41503.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-cluster Subject: Re[2]: Clustering with FreeBSD X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gabriel_ambuehl@buz.ch List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 18:32:27 -0000 Hello Andy, Tuesday, February 10, 2004, 7:17:42 PM, you wrote: > The "Proof of concept" which is weak compare to the > 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. Maybe one could go use the audit framework of TrustedBSD for this kind of work? I know I wanted to do something like that once (mostly some sort of daemon that provides a devices which lists changed files) but I failed (not much of a wonder tho, as I can't really stand C very much and avoid it whenever possible. What can I say, I like my flashy tools for Java ;-) > 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). One of the big advantages is that you effectively have two "independent" file systems: if one FS gets corrupted, you still have the chance that the other one is intact (which is one of the things I never liked about network block devices). And of course you're free to mix and match whatever disks you have on hand. On a quick guess, I'd even venture to say that you could have something like delayed replication, where the changed data is immediately sent to the peer to be stored in a journal but commited only after some time span, thus effectively allowing to guard against admins deleting the wrong stuff (rm -rf /, anyone ;-) and even against hackers. > 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"). Zze Germans speak English? Then why for christs sake do you keep dubbing all those movies (one of the reasons I quit watching TV...). Then again, most would feel sympathethic with the piss drunk butler, of course ;-) Best regards, Gabriel