[nSLUG] will broken rsync be the demise of Gentoo?
donald.teed at gmail.com
Thu Feb 24 20:57:27 AST 2005
* source tarballs are always downloaded, unless one already has one in the
/usr/portage/distfiles area of the same version and rev.
* 'emerge sync' only syncs the ebuild files under /usr/portage and does
any maintenance item such as deleting old slots, moving stuff to
different slots, etc.
These rsync servers timed out on me tonight:
On Thu, 24 Feb 2005 16:59:52 -0400 (AST), Jason Kenney <jason at ohm.ath.cx> wrote:
> On Thu, 24 Feb 2005, Stephen Gregory wrote:
> > On Thu, Feb 24, 2005 at 03:07:17PM -0400, Jason Kenney wrote:
> >> And I can't see how that would help fix the problem. The problem seems to
> >> be (from the original post, this is the first I've heard of this
> >> problem) that rsync itself is broken somehow, so just trying to reduce the
> >> things it is syncing isn't a "solution" at all.
> > Aren't the source.tar.gz files stored under the portage tree in
> > .distributed or something? I haven't used Gentoo in a while so I may
> > not be remembering the setup correctly.
> > At any rate from the origianl post I was under the impression that the
> > fault was a timeout error. If rsync has to calculate and tranmit fewer
> > CRCs it could alleviate the problem. The problem could also load on
> > the remote end. Rsync trades CPU time for network bandwidth. If a
> > client sends a large number of CRCs to check the remote machine has to
> > do more work possibly causing the timeout.
> The tarballs used to be stored under the /var/portage tree somewhere I
> think, but maybe that's been changed.
> Either way, if the problem was "Gentoo doesn't have fast enough hardware",
> I assume that's how the problem would be described, not "rsync is broken".
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG