From owner-freebsd-cluster@FreeBSD.ORG Mon Apr 5 04:52:03 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 CCC0316A4CE for ; Mon, 5 Apr 2004 04:52:03 -0700 (PDT) Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [211.29.132.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8204243D1F for ; Mon, 5 Apr 2004 04:52:01 -0700 (PDT) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from guckloch.zuhause (winax24-048.dialup.optusnet.com.au [211.29.117.48])i35Bpiu21444; Mon, 5 Apr 2004 21:51:45 +1000 Received: from guckloch.zuhause (localhost.zuhause [127.0.0.1]) by guckloch.zuhause (8.12.9/8.12.9) with ESMTP id i35BpAse000931; Mon, 5 Apr 2004 21:51:10 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from localhost (petros@localhost)i35Bp6XP000928; Mon, 5 Apr 2004 21:51:07 +1000 (EST) X-Authentication-Warning: guckloch.zuhause: petros owned process doing -bs Date: Mon, 5 Apr 2004 21:51:06 +1000 (EST) From: Peter Ross X-X-Sender: petros@guckloch.zuhause To: Andy Sporner In-Reply-To: <40711AB9.6010602@nentec.de> Message-ID: <20040405211409.F644@guckloch.zuhause> References: <002401c419e7$76692ac0$2f01a8c0@MICHAELIWZHLNY> <987274454.20040404124312@buz.ch> <40711AB9.6010602@nentec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-cluster@freebsd.org Subject: Re: Request for Cluster Recommendations X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 11:52:03 -0000 On Mon, 5 Apr 2004, Andy Sporner wrote: > I had a rather nice suggestion from somebody "down under" that made > sense and I wanted to get it in. Propably it was me, a German in Melbourne;-) > 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. Great. Congratulations! (I am a little bit ashamed. After a while of unemployment I started to think about some interesting things and discussed it, and when it began to get the right shape, I've got a job and became busy and if spare time was looming I became sick. But I hope it gets better..) > 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. I'm curious to see.. It's in the vnode layer so I assume it's filesystem independent? Regards Peter