[OpenAFS] "vos release" improvement proposals

[Peter Somogyi]

Hi Horst,

Thank you for the notes! See my comments below:
On Wednesday 16 November 2005 18.43, Horst Birthelmer wrote:
>
> The dump format is just right...
> I think your real improvement and valuable contribution should be a
> new protocol just for the replication release.
> Which means the only paradigm you should be breaking is the format
> used by the volume release, _not_ dump and restore.
Yes, this is exactly what I wanted to describe here.
And this new protocol _can_ be strict (=not flexible - I mean) and unique.

> Wouldn't that create the possibility of determining the difference
> between two files (not volumes)?
Yes, this is done exactly by the rsync algorythm - what I'm doing currently.
It calculates checksums of blocks of a "file", first sends only these checksums, and then the RO-side searches for the matching blocks, and server sends only the difference.
(see http://rsync.samba.org/tech_report/)
Regarding my implementation plans: I've aready sent a mail to openafs-devel.

> If yes, how do you deal with different versions on different sites.
> Which lets you have n different versions of a file (n being the
> number of RO volumes)?
I do it at vnode-level (the same way that's done in dumpstuff.c).
I haven't thought enough far which vnode is the _best_ to find to compare on RO side. But any help appreciated for this...
The final result is the most important: to have the same final state which is after "vos release".
It also matches a vnode at RO side, which vnode is marked deleted after it received the corresponding vnode in one.
I will do the same vnode-matching method as the current one.

(A note: to be more precise, when mentioning "vos release" or syncing, I want to change "VolForward" which is used by "vos move" and friends, too. But that's a different story.)

>
> > - profile & optimize "vos release": if anybody have experience when
> > this "vos release" gets extraordinarily slow and knows the
> > environmental reason please write.
>
> AFAIK it's transmitting all changes to the volume but on file basis,
> which generates a lot of traffic for small changes to large files.
Yes, that's what rsync would help.
In real, here I thought about measuring higher execution time which is not proportional to the amount of data to be handled.
Or for example rx starvation while doing some disk operation.

> P.S.: just my two coins ;-) trying to make sure you don't change the
> volume dump and restore parts unnecessarily
I'm not going to change the dump format.

Peter