Date: Tue, 10 Feb 2004 19:33:15 +0100 From: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> To: Andy Sporner <sporner@nentec.de> Cc: freebsd-cluster <freebsd-cluster@FreeBSD.ORG> Subject: Re[2]: Clustering with FreeBSD Message-ID: <444282470.20040210193315@buz.ch> In-Reply-To: <20040210181742.55466.qmail@web41503.mail.yahoo.com> References: <349799726.20040210171004@buz.ch> <20040210181742.55466.qmail@web41503.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444282470.20040210193315>