On Wed, Jan 29, 2003 at 10:41:40PM +1100, Donovan Baarda wrote:
> On Wed, 2003-01-29 at 18:22, Craig Barratt wrote:
> > > I have several patches that I'm planning to check in soon (I'm waiting
> > > to see if we have any post-release tweaking to and/or branching to do).
> > > This list is off the top of my head, but I think it is complete:
> >
> > And I have several things I would like to work on and submit:
> >
> > - Fix the MD4 block and file checksums to comply with the rfc
> > (currently MD4 is wrong for blocks of size 64*n, or files
> > longer than 512MB).
>
> I'm interested in contributing to this effort too; I have helped fix and
> optimise the md4sum implementation for librsync. Once the issue of
> protocol backwards compatibility is resolved, this code could be dropped
> as is into rsync (up to 20% speed increase over current implementation).
>
> However, I also want to change to using the RSA implementation API, and
> submit this code upstream to libmd (it has an optimised md5sum, but only
> the RSA md4sum). That way all the projects that used the RSA
> implementation could benefit from a more optimised md4sum (and can
> contribute bug fixes etc).
>
> > - Adaptive first pass checksum lengths: use 3 or more bytes of the MD4
> > block checksum for big files (instead of 2). This is to avoid almost
> > certain first pass failures on very large files. (The block-size is
> > already adaptive, increasing up to 16K for large files.)
> [...]
> > But before I work on these I would like to make sure there is interest
> > in including them.
>
> IMHO adaptive checksum sizes is critical. People are starting to rsync
> partition images and the maths shows rsync degenerates really badly as
> file sizes get that big.
All well and good. But the question before this thread is
are the changes big and disruptive enough to make a second
branch for the event of a security or other critical bug.
Personally i doubt that such a bug is that likely to emerge
and that if it does we can always create a branch off of
the 2.5.6 tag at that time.
Related to this is that we should make an effort to
incorporate just one of these larger changes at a time
please. If we have to increment the protocol version
number by two or three going from 2.5.6 to 2.5.7 that is OK
by me.
I am inclined to prioritize the checksum fixes. They are
central to rsync and i'd like them to get a maximum of
testing as early in the new cycle as possible. This is the
one scaling deficiency we have a decent chance of fixing.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
