Request for Cluster Recommendations

[Andy Sporner]

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.