Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] RFC: Dropping rsync as a tree distribution method
Date: Tue, 18 Dec 2018 11:55:33
Message-Id: 1545134118.924.3.camel@gentoo.org
In Reply to: Re: [gentoo-project] RFC: Dropping rsync as a tree distribution method by Andrew Savchenko
1 On Tue, 2018-12-18 at 12:55 +0300, Andrew Savchenko wrote:
2 > On Sat, 15 Dec 2018 23:15:47 -0500 Alec Warner wrote:
3 > > Hi,
4 > >
5 > > I am currently embarking on a plan to redo our existing rsync[0] mirror
6 > > network. The current network has aged a bit. Its likely too large and is
7 > > under-maintained. I think in the ideal case we would instead pivot this
8 > > project to scaling out our git mirror capabilities and slowly migrate all
9 > > consumers to pulling the git tree directly. To that end, I'm looking for
10 > > blockers as to why various customers cannot switch to pulling the gentoo
11 > > ebuild repository from git[1] instead of rsync.
12 > >
13 > > So for example:
14 > >
15 > > - bandwidth concerns (preferably with documentation / data.)
16 > > - Firewall concerns
17 > > - CPU concerns (e.g. rsync is great for tiny systems?)
18 > > - Disk usage for git vs rsync
19 > > - Other things i have not thought of.
20 >
21 > My main concern with git is downlink fault tolerance. If rsync
22 > connection is broken, it can be easily restored without much data
23 > retransmission. If git download connection is broken, it has to
24 > start all over again. So there are cases where rsync will be always
25 > much more preferable than git.
26 >
27
28 I think this mostly applies to the initial clone, and in this case
29 the git bundles (that will be) offered by Infra should solve it. You'd
30 download them over regular HTTP(S) connection which you can freely
31 resume.
32
33 --
34 Best regards,
35 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature