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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
