Date: Tue, 10 Feb 2004 10:17:42 -0800 (PST) From: Andy Sporner <asporner@yahoo.com> To: gabriel_ambuehl@buz.ch, Andy Sporner <sporner@nentec.de> Cc: freebsd-cluster <freebsd-cluster@FreeBSD.ORG> Subject: Re: Clustering with FreeBSD Message-ID: <20040210181742.55466.qmail@web41503.mail.yahoo.com> In-Reply-To: <349799726.20040210171004@buz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040210181742.55466.qmail>