Travis Tilley posted <416A6264.9020805@gentoo.org>, excerpted below, on
Mon, 11 Oct 2004 06:37:24 -0400:
> Duncan wrote:
>> .. About 3 and a half minutes. I just timed it.
>
> rm -rf /usr/portage and time it again.
Well:
#ll /usr/portage
lrwxrwxrwx 1 root root 6 Sep 26 18:02 /usr/portage -> /mnt/p/
I don't have /usr/portage, except as a symlink, for those apps that can't
follow PORTDIR=/mnt/p in /etc/make.conf, so unless emerge sync is one of
those (and let's /hope/ not), your suggestion above would have little
impact, here.
However, removing $PORTDIR is what I assume you meant, so after umounting
/mnt/p/src ($DISTDIR) and /mnt/p/pkg ($PKGDIR) so as not to lose them (I
learned my lesson when I presumed portage would know enough not to attempt
to rsync its $DISTDIR and $PKGDIR =:^(, but that's been covered in
bugzilla already), I backed up /mnt/p and deleted it, then timed an emerge
sync:
real 3m1.038s
user 0m6.512s
sys 0m25.001s
To get a better direct comparison, I then deleted it again, restored my
backup copy, and (after a few minutes lag time to prevent being called on
the carpet for syncing to quickly) did a standard emerge sync.
real 2m27.357s
user 0m30.395s
sys 0m10.033s
Two and a half minutes, that time, as compared to three minutes total
(from blank) sync, and three and a half(ish) minutes yesterday normal
sync. Note that while I consider all three timings "reasonable", I /do/
occasionally get stuck with a sync mirror that's feeding the initial
file at speeds turning over the tens and hundreds files counter, rather
than the thousands and ten-thousands files counters, in which case I
usually ^C abort the sync and try again, for a different rsync server.
The point is, there's enough variability at that end, that no conclusion
can be drawn due to the 30-second-ish differences in timings that I
measured.
In any case, 45 minutes on a 5Mbit connection as claimed by the upline
poster, definitely means something other than raw portage tree size or
local pipe bandwidth is the problem. Someone mentioned it took them about
that long with a 100MHz Pentium and 128M memory, which is what I suggested
the problem may be earlier, local machine performance, not tree size or
bandwidth limitations.
--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin
--
gentoo-dev@gentoo.org mailing list
Mon, 11 Oct 2004 06:37:24 -0400:
> Duncan wrote:
>> .. About 3 and a half minutes. I just timed it.
>
> rm -rf /usr/portage and time it again.
Well:
#ll /usr/portage
lrwxrwxrwx 1 root root 6 Sep 26 18:02 /usr/portage -> /mnt/p/
I don't have /usr/portage, except as a symlink, for those apps that can't
follow PORTDIR=/mnt/p in /etc/make.conf, so unless emerge sync is one of
those (and let's /hope/ not), your suggestion above would have little
impact, here.
However, removing $PORTDIR is what I assume you meant, so after umounting
/mnt/p/src ($DISTDIR) and /mnt/p/pkg ($PKGDIR) so as not to lose them (I
learned my lesson when I presumed portage would know enough not to attempt
to rsync its $DISTDIR and $PKGDIR =:^(, but that's been covered in
bugzilla already), I backed up /mnt/p and deleted it, then timed an emerge
sync:
real 3m1.038s
user 0m6.512s
sys 0m25.001s
To get a better direct comparison, I then deleted it again, restored my
backup copy, and (after a few minutes lag time to prevent being called on
the carpet for syncing to quickly) did a standard emerge sync.
real 2m27.357s
user 0m30.395s
sys 0m10.033s
Two and a half minutes, that time, as compared to three minutes total
(from blank) sync, and three and a half(ish) minutes yesterday normal
sync. Note that while I consider all three timings "reasonable", I /do/
occasionally get stuck with a sync mirror that's feeding the initial
file at speeds turning over the tens and hundreds files counter, rather
than the thousands and ten-thousands files counters, in which case I
usually ^C abort the sync and try again, for a different rsync server.
The point is, there's enough variability at that end, that no conclusion
can be drawn due to the 30-second-ish differences in timings that I
measured.
In any case, 45 minutes on a 5Mbit connection as claimed by the upline
poster, definitely means something other than raw portage tree size or
local pipe bandwidth is the problem. Someone mentioned it took them about
that long with a 100MHz Pentium and 128M memory, which is what I suggested
the problem may be earlier, local machine performance, not tree size or
bandwidth limitations.
--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin
--
gentoo-dev@gentoo.org mailing list