Bug 647908

Summary:	>=sys-apps/portage-2.3.24 takes forever to sync due to new use of gemato
Product:	Portage Development	Reporter:	Rick Harris <rickfharris>
Component:	Unclassified	Assignee:	Portage team <dev-portage>
Status:	RESOLVED INVALID
Severity:	normal	CC:	mgorny
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Rick Harris 2018-02-16 22:46:23 UTC

Since updating sys-apps/portage from 2.3.19 to 2.3.24, the portage tree can no longer be synced in a timely fashion.

The syncing process hangs at:
INFO:root:Verifying /usr/portage...

The use of gemato adds around 15 minutes to the sync process on a modern PC.

Downgrading to 2.3.19 seems to be the only solution at this stage.

Comment 1 Zac Medico gentoo-dev

2018-02-17 00:04:06 UTC

You can disable it with a setting like this in /etc/portage/repos.conf:

[gentoo]
sync-rsync-verify-metamanifest = no

It can also be disabled at build time with a setting like this in /etc/portage/package.use:

sys-apps/portage -rsync-verify

Comment 2 Michał Górny archtester

2018-02-17 08:22:46 UTC

This was noted in the news item. This is a technical limitation, it can't be made faster than your filesystem. That said, you're probably using a horribly bad filesystem, and I would be surprised if Portage wouldn't be extremely slow on it anyway.

Comment 3 Rick Harris 2018-02-17 08:47:52 UTC

Awesome thanks guys and apologies for a false alarm, seems it's slow by design.

I'm using ext4, is that no good anymore?

Hard drives aren't solid state so that might be the problem:
# hdparm -tT /dev/sda2

/dev/sda2:
 Timing cached reads:   8044 MB in  2.00 seconds = 4023.85 MB/sec
 Timing buffered disk reads: 340 MB in  3.00 seconds = 113.27 MB/sec

Anyway, disabled it now :)

Comment 4 Michał Górny archtester

2018-02-17 09:01:45 UTC

/dev/sda:
 Timing cached reads:   1558 MB in  2.00 seconds = 778.87 MB/sec
 Timing buffered disk reads: 184 MB in  3.02 seconds =  60.90 MB/sec

Since the ebuild repository uses a lot of small files, it is subject to fragmentation a lot. Using a completely separate filesystem for it reduces the performance problems. Preferably use a filesystem better suited for small files such as btrfs or reiserfs (or possibly overlayfs on top of squashfs).