From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Replica - just a thought. Message-ID: <20040210132815.L17981@cackle.proxima.alt.za> References: <20040210124725.K17981@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Fco.J.Ballesteros on Tue, Feb 10, 2004 at 12:14:31PM +0100 Date: Tue, 10 Feb 2004 13:28:16 +0200 Topicbox-Message-UUID: dc625a0a-eacc-11e9-9e20-41e7f4b1d025 On Tue, Feb 10, 2004 at 12:14:31PM +0100, Fco.J.Ballesteros wrote: > > perhaps I didn't understand you, but if you dump > a replica client, as I think you did, then you'd need > to sync to the original sources to detect conflicts. > Well, no, although what you say is right. (a) I actually mounted one ISO image and merged it into the dump, struck me as obvious; (b) It is hard to keep two sites in sync without an arbitration, and in my case I want to keep a pristine copy of the Plan 9 distribution handy and so does Bell Labs. > AFAIK, the replica scheme works as long as each > client gets in sync with the same master. > Yes, that's the arbitration point. It eliminates the need to define masters and slaves, too. > And anyway, if a corrupt entry arises, you'd get it > anyway (be it dump or replica), so there's no protection > but to be able to recover if something goes wrong. > The recent spate of problems seem to me to be finger trouble, like compiling kernels on the distribution server. Replica lacks checksumming and that is a serious flaw, but it's not a problem my approach addresses. To me the benefit lies in the ditraibution format, file-level dump instructions, if such things can be represented. > But maybe I'm missing your point. No, I'm the one with the half-baked idea. But I think that discussion will lead to a ripe fruit :-) ++L