From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2343f07a0d7a83b20c12ce62351ce086@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 29 Dec 2008 19:57:32 -0500
In-Reply-To: <64D70190-E23C-49E7-914B-5EAEB39823CE@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Changelogs & Patches?
Topicbox-Message-UUID: 73db5ae2-ead4-11e9-9d60-3106f5b1d025

> ...but your article answered that last question completely. Although,
> I wonder whether direct transfer of history between two venti
> servers would be possible.

if one were to transfer history between two fs with the same on-disk
format, a simple device copy would be sufficient.  i was moving from
a 32-bit 4k block fs to geoff's 64 bit work with 8k blocks.

history is not a property of venti.  venti is a sparse virtual drive
with ~2^80 bits storage.  blocks are addressed by sha1 hash of
their content. fossil is the fileserver.  the analogy would be a change
in fossil format.  my technique would work for fossil, too.

> P.S. I also didn't quite understand the business of synchronizing Qids.
> I have always thought that they are only meaningful for the duration
> of the server's lifetime and thus all applications are quite immune to
> potential Qid changes as long as the connection get dropped and
> re-established. Or was it that your goal was to migrate so seamlessly
> that *running* applications wouldn't notice?

that's okay.  russ think's i'm nuts on this point, too.

perhaps the paper wasn't fully clear.  i wanted to make the assertion
that if on the original fs,qid(patha) == qid(pathb) then on the new
fs, qid(patha') == qid(pathb').  the qids weren't the same.  for
various reasons (i.e.  not every copy of every file makes it to a
dump), they can't be.  it's just a very complicated way of saying, i
didn't want to recopy the same data needlessly and increase the size
of the fs.  i just couldn't think of an easy way of making the same
assertion another way without reading every file for each day of
the dump.  remember, the original fs was a pentium ii with a
100mbit ethernet card.  it's still took 2 weeks to copy the data
to the new fs.

and russ is right in that it was overkill.  but, hey, if it's worth doing,
it's worth doing in grand excess.

oh, by the way, the replica db's are reusable.  they could also, if
one wished by generated by the fs as part of the dump process.

- erik