Re: kernel.bkbits.net off the air

[Benoit Poulot-Cazajous]

Andreas Schwab <schwab@xxxxxxx> writes:

> Andrea Arcangeli <andrea@xxxxxxx> writes:
> 
> > On Wed, Nov 12, 2003 at 10:35:22PM +0100, Benoit Poulot-Cazajous wrote:
> >> Andrea Arcangeli <andrea@xxxxxxx> writes:
> >> 
> >> > the usual problem, and the reason we need a sequence number (increased
> >> > before and after the repo update). A file lock not.
> >> 
> >> Or a file that contains md5sums of the other files in the tree. 
> >> After the rsync, you recompute the md5sums file, and if it does not match,
> >> rsync again. As a bonus feature, the md5sums file can be pgp-signed.
> >
> > agreed, this would work too and it has the advantage of working with the
> > mirrors too as far as the per-file updates are atomic (should always be
> > the case). This has the only disavanage of forcing the client and the
> > server to read all file contents (I normally don't rsync with -c).
> 
> This is not necessary, you only need to recompute the md5sums of changed
> files.

Well, if you really want to optimize (md5sum is fast, faster than a typical hd,
and much faster than gcc), check the most recent file. If its md5sum does not
match, rsync again. 
There are many ways to optimize the md5sum of the whole tree, when a previous
tree with a trusted md5sum file is available. "find -ls" can help there. But
make sure not to over-optimize, as servers with wrong md5sum files
will be DDOSed by their clients ;-)

  -- Benoit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/