Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] RFC: Dropping rsync as a tree distribution method
Date: Sun, 16 Dec 2018 11:34:22
Message-Id: CAGfcS_=n_JBEx5vubFVEXH6ZUrKgMN3f=HHjtfW1eGOe=W0BBw@mail.gmail.com
In Reply to: [gentoo-project] RFC: Dropping rsync as a tree distribution method by Alec Warner
1 On Sat, Dec 15, 2018 at 11:15 PM Alec Warner <antarus@g.o> wrote:
2 >
3 > [1] Rich talked about some downsides earlier at https://lwn.net/Articles/759539/; but while these are challenges (some fixable) they are not necessarily blockers.
4
5 The thread has already touched on a few of those comments. Despite
6 only six months elapsing since I wrote that email, #1 no longer
7 applies, and it sounds like #4 may not be as much of a concern. As
8 you've already stated #3 can be easily addressed - setting up a git
9 mirror is very easy.
10
11 I think #2 is more of a fundamental design difference that probably
12 will never go away. If your tree is a year old then git WILL take
13 longer and transfer more data than rsync. My guess is that it will
14 also cost more IO server-side than rsync, but it probably will be
15 cheaper in CPU. However, I bet that 95% of our users sync weekly or
16 daily and in that use case it is going to go a lot faster, and
17 probably be less mirror load as well, and it will be a TON less IO
18 load on the client side. I'm not sure how much IO cost there is to
19 git garbage collection - that might offset this in the common shallow
20 clone scenario.
21
22 I'd suggest that those with concerns give it a shot using Zac's
23 suggested settings and see how it goes. Really all you have to do is
24 delete your local repo and adjust your sync settings and resync. I
25 think the local disk use is going to be the biggest source of user
26 objection and I'm interested in what people observe here.
27
28 --
29 Rich

Replies