From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] /n/sources/contrib/ From: "Russ Cox" Date: Sun, 18 Nov 2007 21:15:05 -0500 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20071119021515.D29241E8C4D@holo.morphisms.net> Topicbox-Message-UUID: 006cf2b0-ead3-11e9-9d60-3106f5b1d025 >> The web page Uriel pointed at contains a recipe but no explanation. >> The explanation is that every night the file /n/sources/lsr is updated >> with a list of all the files on sources and their modification times, >> sizes, and content hashes. You can copy lsr and then diff it against >> your previous copy of lsr to find out which files have changed >> and need to be updated in your "replica". >> >> It's very easy. Much easier than trying to build something like this >> on top of venti or fossil, and with the added benefit that you can >> selectively mirror, excluding some trees as desired. > > why would coping the changed bits of the > active arena be so hard? is it too hard to update > the index? > > with ken's fs, copying from superblockn->w-address to > superblockn+1->waddr and recover is sufficient. > the bonus is that history works. it's not necessarily hard -- you just write the code -- but it's more fragile to do this kind of exact mirroring, because you can't make any local modifications without breaking the mirroring. if you decide you don't want to keep some huge subtree, for example, or you want to add a few locally maintained files. the file system is a good interface -- witness all of plan 9 -- and if you're going to start working at a lower level i just think you need a much more compelling reason. if your goal is to have a live backup of a system, then some disk-level thing might be exactly right. but for having a local mirror of sources, the lsr file and a simple script to run the cp commands is simple and more flexible. russ