9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /n/sources/contrib/
Date: Sun, 18 Nov 2007 21:15:05 -0500	[thread overview]
Message-ID: <20071119021515.D29241E8C4D@holo.morphisms.net> (raw)
In-Reply-To: <f8234d114859c5c5eb2567255a17c1b6@coraid.com>

>> 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


  parent reply	other threads:[~2007-11-19  2:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-17  5:35 lucio
2007-11-17 18:05 ` andrey mirtchovski
2007-11-17 18:55   ` lucio
2007-11-17 18:56   ` lucio
2007-11-17 22:00   ` erik quanstrom
2007-11-18  4:39     ` lucio
2007-11-18  5:08       ` erik quanstrom
2007-11-18  5:30         ` lucio
2007-11-18 10:25           ` johnny
2007-11-18 11:04             ` lucio
2007-11-18 11:33     ` roger peppe
2007-11-18 13:24       ` lucio
2007-11-18 14:18       ` erik quanstrom
2007-11-18 18:17       ` johnny
2007-11-19 16:29         ` roger peppe
2007-11-18 21:23       ` johnny
2007-11-17 18:13 ` Uriel
2007-11-17 18:58   ` lucio
2007-11-18 15:17 ` Russ Cox
2007-11-18 15:29   ` erik quanstrom
2007-11-18 18:26     ` Francisco J Ballesteros
2007-11-19  2:15     ` Russ Cox [this message]
2007-11-19 17:38       ` erik quanstrom
2007-11-19 17:53         ` Russ Cox
2014-05-23  7:20 David Hoskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071119021515.D29241E8C4D@holo.morphisms.net \
    --to=rsc@swtch.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).