Re: ftpsync README rewrite
Lee Winter (lee.j.i.winter@gmail.com) wrote on 17 September 2009 21:58:
>On Thu, Sep 17, 2009 at 8:34 PM, Carlos Carvalho <carlos@fisica.ufpr.br> wrote:
>> Joerg Jaspert (joerg@debian.org) wrote on 17 September 2009 10:20:
>> >On 11874 March 1977, Lee Winter wrote:
>
>> The problem with this approach is that it needs changes (non-trivial
>> ones, btw) to rsync. That doesn't "catch" because mirrors change their
>> versions very slowly. An example is that version 3 is much better but
>> still not widely used.
>
>I expect to change the upstream rsync and the scripts on both
>machines. So upgrading the downstream can happen at its own pace.
As I said in the other mailing list, it sure can happen. It's just
that the probability is on the order of the inverse of Avogadro's
number :-)
>Once the file scan is unnecessary the checksums will be the remaining
>burden, which will then be worth eliminating.
Again as I said in the other mailing list, repeating here (sligthly
rephrased) for those that won't see it:
The big problem with keeping/updating file lists is not the file list,
which can (and should) be easily generated separately by mirrors;
DEBIAN ALREADY HAS THEM!!!
If you really want to avoid the scan in your mirrors use the mirror
package. Most mirrors offer ftp service.
The difficulty with removing the scan is that it makes the update
process transactional; to have reliability you have to deal with all
sorts of failures.
The vast majority of mirrors use a ~10-line script, which is easy to
write and maintain, even though they're naive. ftpsync is bigger but
not difficult to understand *and trust*, because the reliability is
all provided by rsync. OTOH, ours is so much better in every aspect
(efficiency, locking, error checking, etc) and, I believe, as reliable
as plain rsync/ftpsync. BUT... it is an 800-line monster full of
subtleties, where a seemingly innocent change may corrupt your mirror
and may only be noticed months later.
How many admins would use it? NOBODY. Do you think the distribution
managers would recommend it? Only if they're kamikazes. What would be
the advantage for Debian? Put some competition in gentoo with their
half-an-hour updates! :-)
Naaaahhhh.... 4 updates/day are quite enough. The situation will
change only with the increase of ram.
So why did I write rsmir? Because we work at the limit and still make
a point in providing top-quality service. So much so that I asked the
closer downstream mirrors to send me back the file list build time for
every update, and I check it *always*. Without rsmir we wouldn't be
able to do what we do now.
>Where can I find rsmir?
I don't distribute it. The probability of it being useful is similar
to you succeeding in changing upstream rsync: 1/6x10^23...
Reply to: