Clustering with FreeBSD

[Gabriel Ambuehl]

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