After a new sync, the initial check for what needs upgrading takes too long. Subsequent checks are lightning fast. First check after re-syncing: # time emerge --pretend -vD world [deleted] real 487m36.761s user 21m36.239s sys 0m31.150s Next check: # time emerge --pretend -vD world [deleted] real 0m19.083s user 0m0.590s sys 0m0.050s This has been happening since the upgrade to portage 2.1. The rebuilding of metadata is fast now, but the first use of some of that metadata is deathly slow. $ emerge --info Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r7 i686) ================================================================= System uname: 2.6.16-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.15 ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/init.d /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache confcache distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv" GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo ftp://mirror.datapipe.net/gentoo ftp://gentoo.chem.wisc.edu/gentoo/ ftp://dsse.con.can.ibm.com/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/dmcbride/cvs/portdir-ibm/gentoo-ebuilds" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bzlib cdparanoia cdr cli crypt cups db2 dlloader doc dri dvd dvdr dvdread eds emboss encode esd exif expat ffmpeg fftw flac flash foomaticdb fortran ftp gb gcj gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 imagemagick imap imlib ipv6 isdnlog ithreads jpeg kde lcms ldap libg++ libwww mad mbox mikmod milter mime ming mmap mmx mng motif mp3 mpeg ncurses nls nptl nvidia ogg openal opengl oss pam pcre pda pdflib perl png posix pppd python qt qt3 qt4 quicktime readline reflection samba scanner sdl session sockets sox spell spl ssl tcpd threads tidy tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wxwindows xine xml xml2 xmms xorg xsl xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nvidia video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Happens to me too, except not quite that extreme. real 5m41.618s user 0m59.684s sys 0m21.733s real 0m4.872s user 0m2.256s sys 0m0.696s Compiling is also slower than it used to be, although I'm not sure if that's related. I just reinstalled Gentoo after a disk failure. Sorry, but I can't paste an emerge --info - I haven't finished emerging gnome-terminal yet and xterm won't let me copy and paste.
Erm, folks - maybe, use hdparm and turn DMA on for your drives? Really, it doesn't take even remotely that time.
I can't even count the number of people who have told me to turn on DMA. However, it has never been off that I can tell - I'm using an SATA disk. hdparm doesn't work with these - it's IDE only. And "Really, it doesn't take even remotely that time" - really, it does. Here. Consistantly. It shouldn't. But it does.
Assuming you've ran emerge --metadata since upgrading portage (I assume you have if this is the same as the forums thread) can you check `hdparm -tT /dev/your_disk` just to confirm that the disk is running normally, please? If that's not it, can you give the output of `mount | grep /dev/` please?
# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1500 MB in 2.00 seconds = 751.55 MB/sec Timing buffered disk reads: 116 MB in 3.05 seconds = 38.09 MB/sec # mount | grep /dev/ /dev/sda5 on / type ext3 (rw) devpts on /dev/pts type devpts (rw) /dev/sda1 on /boot type ext2 (rw,noatime) /dev/sda6 on /linux2 type ext3 (rw) /dev/sda7 on /home type reiserfs (rw) none on /dev/shm type tmpfs (rw) none on /dev/shm type tmpfs (rw) And the metdata runs automatically after syncing - does this mean I should sync and metadata one after another? In effect, doing two metadata creations for a single sync? It does seem to help (now 1m40.159s of real time after doing "emerge --sync ; emerge --metadata" - still long, but liveable). But then the question I have is why? What is re-doing the metadata doing that wasn't done the first time? If it's just loading the cache, wouldn't the metadata phase of "emerge --sync" load the cache?
This could be one of the issues discussed in bug #124041.
(In reply to comment #5) > none on /dev/shm type tmpfs (rw) > none on /dev/shm type tmpfs (rw) Do you have any idea why this is listed twice? It should only be listed once... I don't know if this is related to your issue and am just grabbing for straws - if it was a regular bug there'd be dozens of reporters as soon as portage was marked ~arch - but anything to limit the possibilities.
Zac Medico is right. After upgrading to the unstable portage 2.1.1_pre2-r8, the time is down to 2m27.457s, with no intervening re-doing of any metadata. Turns out, /usr/portage is a symlink to /home/usr/portage since /usr doesn't have enough space. *** This bug has been marked as a duplicate of 137965 ***
