From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 26 May 2008 14:58:57 +0200 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Message-ID: <20080526125857.GB10890@nibiru.local> References: <20080525075632.GA30260@nibiru.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [9fans] Fossil+Venti on Linux Topicbox-Message-UUID: aca7c492-ead3-11e9-9d60-3106f5b1d025 * a@9srv.net wrote: > I don't think venti+fossil will do what you're looking for, however, at least > not without some additional machinery. Fossil doesn't do any replication or > fail-over: it must talk to zero or one ventis. Venti doesn't automatically > replicate anything, either, although that's pretty easy to script if you're > willing to accept the exposure of a cron job. I intend to code an special cluster-venti, which automatically propagates new blocks to it's peers and ask around if it can't some block. This would bit be a bit lazy replication (depends on how long propagation takes). As long as the critical data (metadata, ...) are distributed fast enough or otherwise backed-up properly, so at least an reasonably recent snapshot can always be retrieved, this IMHO would make it much easier/faster to get some services up on another machine. Doesn't need to have a true failover fs, I just want to start with the last snapshot quickly (as I now would do with a tar'ed backup). My first excercise will be some LOC which dump out the new blocks to some dir and build some separate daemon which sends them out to the peer venti's. So I only have to back-up fossil's local metadata. Since the machines tend to have a lot of equal data, much space and traffic can be saved. As a more sophisticated aproach, I'm planning an *real* clustered venti, which also keeps track of block atime's and copy-counters. This way, seldomly used blocks can be removed from one node as long as there are still enough copies in the cluster. (probably requires redesign of the log architecture). This still isn't an replicated/distributed fs, but an clustered block storage, maybe even as a basis for an truely replicated fs. BTW: with a bit more logic, we even could build something like Amazon's S3 on that ;-) Actually, I don't need an replicated fs at all, just an space and traffic efficient backup mechanism, which shares data with the local fs'es. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------