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