[nSLUG] will broken rsync be the demise of Gentoo?

Donald Teed donald.teed at gmail.com
Thu Feb 24 22:37:39 AST 2005


I've made a discovery related to the rsync problem...

I found that I had left X running on the console with a couple of
mozilla browsers.  My Belkin KVM often sends a series of
digits to the console I am leaving, and it had sent many 1's
(probably for a couple of days) into the address bar of mozilla.

X and Mozilla were not responding, so I aborted with Ctrl-Alt-backspace.

At the time they were frozen, X and mozilla had pushed up
the load factor to about 1.8 (on a machine that isn't doing
much work).  I used ssh session on it all day and pine
without the cycles making any noticable impact on
performance.

emerge-webrsync had completed OK while under this load.

When the X session was killed I tried emerge sync again.
It immediately ran OK.  So it seems there is some
bogus problem with rsync and CPU cycles.
That would explain why some people report that
only some machines in their server room had the problem
while others were fine.

In my case, the load factor wasn't really something
that should have interfered with this.  The box
in question was a dual PII-450 with 512 MB RAM.

Weird problem but it looks like I'm finished with it.

On Thu, 24 Feb 2005 20:57:27 -0400, Donald Teed <donald.teed at gmail.com> wrote:
> In Gentoo...
> 
> * 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:
> rsync://216.170.153.145/gentoo-portage
> rsync://216.194.67.33/gentoo-portage
> rsync://63.150.226.21/gentoo-portage
> 
> 
> 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".
> >
> > Jason
> >
> >
> > _______________________________________________
> > nSLUG mailing list
> > nSLUG at nslug.ns.ca
> > http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug
> >
> > 
> >
> >
>

!DSPAM:421e8f75167801281684697!




More information about the nSLUG mailing list