# Sync Portage lahm

## manuels

Moin,

jedesmal, wenn ich ein "emerge sync" mache, kommen u.a. folgender output:

```
deleting x11-libs/ecore/files/digest-ecore-1.0.0.20040313_pre4

deleting x11-libs/ecore/ecore-1.0.0.20040313_pre4.ebuild

deleting x11-misc/shared-mime-info/shared-mime-info-0.11.ebuild

deleting x11-misc/shared-mime-info/files/digest-shared-mime-info-0.11

deleting x11-misc/iconbar/iconbar-0.9.1.20040221.ebuild

deleting x11-misc/iconbar/files/digest-iconbar-0.9.1.20040221

deleting x11-misc/entrance/files/digest-entrance-0.9.0.20040313

deleting x11-misc/entrance/entrance-0.9.0.20040313.ebuild

deleting x11-terms/gnome-terminal/gnome-terminal-2.5.90.ebuild

deleting x11-terms/gnome-terminal/files/digest-gnome-terminal-2.5.90

deleting x11-themes/sylpheed-iconset/sylpheed-iconset-20030523.ebuild

deleting x11-themes/sylpheed-iconset/sylpheed-iconset-0.8.7.ebuild

deleting x11-themes/sylpheed-iconset/sylpheed-iconset-0.8.3.ebuild

deleting x11-themes/sylpheed-iconset/files/digest-sylpheed-iconset-20030523

deleting x11-themes/sylpheed-iconset/files/digest-sylpheed-iconset-0.8.7

deleting x11-themes/sylpheed-iconset/files/digest-sylpheed-iconset-0.8.3

deleting x11-themes/gnome-themes/gnome-themes-2.5.92.ebuild

deleting x11-themes/gnome-themes/files/digest-gnome-themes-2.5.92

deleting x11-wm/metacity/metacity-2.7.1.ebuild

deleting x11-wm/metacity/files/digest-metacity-2.7.1

200 files...

Number of files: 79216

Number of files transferred: 2679

Total file size: 61854159 bytes

Total transferred file size: 3957309 bytes

Literal data: 3957309 bytes

Matched data: 0 bytes

File list size: 1758234

Total bytes written: 43049

Total bytes read: 3574504

wrote 43049 bytes  read 3574504 bytes  11429.87 bytes/sec

total size is 61854159  speedup is 17.10

>>> Updating Portage cache... \oggvorbis

|oggvorbis

/using package de

/perl

-perl

/grep: /etc/apache/conf/apache.conf: Datei oder Verzeichnis nicht gefunden

-has_version() in global scope: app-office/phprojekt-4.0-r1

has_version() in global scope: app-office/phprojekt-4.0-r1

has_version() in global scope: app-office/phprojekt-4.0-r1

\has_version() in global scope: app-office/phprojekt-4.1

has_version() in global scope: app-office/phprojekt-4.1

has_version() in global scope: app-office/phprojekt-4.1

-has_version() in global scope: dev-db/phpmyadmin-2.5.6_rc1

has_version() in global scope: dev-db/phpmyadmin-2.5.6_rc1

has_version() in global scope: dev-db/phpmyadmin-2.5.6_rc1

|has_version() in global scope: dev-lang/squeak-3.4.1-r1

has_version() in global scope: dev-lang/squeak-3.4.1-r1

/has_version() in global scope: dev-lang/squeak-3.4.1-r2

has_version() in global scope: dev-lang/squeak-3.4.1-r2

\true

|true

/python

-mysql

-true

\true

|true

/true

|ssl

/ssl

-ssl

\ssl

|gnome

/gnome

opengl

-gnome

\gnome

opengl

-gnome

\gnome

\best_version() in global scope: dev-perl/math-pari-2.010500

-has_version() in global scope: dev-php/jpgraph-1.12.2

has_version() in global scope: dev-php/jpgraph-1.12.2

has_version() in global scope: dev-php/jpgraph-1.12.2

has_version() in global scope: dev-php/jpgraph-1.12.2

/has_version() in global scope: dev-php/mod_php-4.3.2-r2

has_version() in global scope: dev-php/mod_php-4.3.2-r2

-has_version() in global scope: dev-php/mod_php-4.3.2-r3

has_version() in global scope: dev-php/mod_php-4.3.2-r3

\has_version() in global scope: dev-php/mod_php-4.3.2-r4

has_version() in global scope: dev-php/mod_php-4.3.2-r4

|has_version() in global scope: dev-php/mod_php-4.3.2-r5

has_version() in global scope: dev-php/mod_php-4.3.2-r5

/has_version() in global scope: dev-php/mod_php-4.3.3

has_version() in global scope: dev-php/mod_php-4.3.3

-has_version() in global scope: dev-php/mod_php-4.3.3-r1

has_version() in global scope: dev-php/mod_php-4.3.3-r1

\has_version() in global scope: dev-php/mod_php-4.3.3-r2

has_version() in global scope: dev-php/mod_php-4.3.3-r2

|has_version() in global scope: dev-php/mod_php-4.3.3-r3

has_version() in global scope: dev-php/mod_php-4.3.3-r3

/has_version() in global scope: dev-php/mod_php-4.3.3_rc3

has_version() in global scope: dev-php/mod_php-4.3.3_rc3

-has_version() in global scope: dev-php/mod_php-4.3.4

has_version() in global scope: dev-php/mod_php-4.3.4

\has_version() in global scope: dev-php/mod_php-4.3.4-r1

has_version() in global scope: dev-php/mod_php-4.3.4-r1

|has_version() in global scope: dev-php/mod_php-4.3.4-r2

has_version() in global scope: dev-php/mod_php-4.3.4-r2

/has_version() in global scope: dev-php/mod_php-4.3.4-r3

has_version() in global scope: dev-php/mod_php-4.3.4-r3

-has_version() in global scope: dev-php/mod_php-4.3.4-r4

has_version() in global scope: dev-php/mod_php-4.3.4-r4

-has_version() in global scope: dev-php/phpgroupware-0.9.14.007

has_version() in global scope: dev-php/phpgroupware-0.9.14.007

has_version() in global scope: dev-php/phpgroupware-0.9.14.007

\zlib

|zlib

/zlib

```

Hab gehört, dass das nicht so schlimm ist. ok.

aber das dauert jedesmal ellen lang.

wenn ich täglich emerge sync mache, dauert das ganze länger als 30 min...

ist das bei euch auch so?

Tschö mit ö

Manuel

----------

## sirro

Welche portage-version? Es gab mal welche die ungefordert Debugoutput ausspuckten...

----------

## manuels

die neuste: portage-2.0.50-r3

----------

## SvenFischer

worin liegt eigentlich der Unterschied zwischen

emerge sync

und

emerge rsync -> mach ich immer

----------

## Sas

Es gibt keinen.

----------

## Genone

```
emerge rsync
```

 wird irgendwann mal geändert, so dass es rsync installiert.

----------

## manuels

...hat keiner ne idee?

ist denn ne halbe stunde normal nur fürs rechnen (das runterladen geht echt flott)

----------

## amne

20 - 30 Minuten für nen sync ist auf meinem Pentium MMX 233 auch recht normal.

Was für ne Hardware setzt du ein?

----------

## manuels

Athlon XP 2,4+ mit 512 MB ram...

normal ist das nicht.

----------

## amne

Dann ist das schon ein bissi langsam. DMA ist für die Platte aktiviert?

----------

## manuels

jo, mit hdparm eigentlich alles richtig eingestellt.

kann ich den portage irgendwie vielleicht zurücksetzen?

----------

## manuels

^^ hype ^^

----------

## stahlsau

hi,

hab das gleiche Problem. Bei "updating portage cache" spuckt der immer so'n mist aus, und es dauert ewig...

```
on() in global scope: net-www/phpwebsite-0.9.3_p1-r1

has_version() in global scope: net-www/phpwebsite-0.9.3_p1-r1

has_version() in global scope: net-www/phpwebsite-0.9.3_p1-r1                  /has_version() in global scope: net-www/phpwebsite-0.9.3_p2

has_version() in global scope: net-www/phpwebsite-0.9.3_p2

has_version() in global scope: net-www/phpwebsite-0.9.3_p2                     -has_version() in global scope: net-www/phpwebsite-0.9.3_p2-r1

has_version() in global scope: net-www/phpwebsite-0.9.3_p2-r1

has_version() in global scope: net-www/phpwebsite-0.9.3_p2-r1                  /ssl

zlib                                                                           -perl                                              
```

----------

## Realmaker

Ich hab mal im Forum gesucht und es scheint mehrere zu geben die dieses PRoblem haben, aber es wurde auch gesagt, dass es eigentlich nichts schlimmes heißt.

----------

## stahlsau

jo, schlimm ists nicht, zumindest gibts keine unresolved symbols oder irgendsowas, mit dem ich mich sonst noch hier rumplagen muß  :Wink: 

Allerdings braucht emerge sync jetzt immer 20 minuten, und das ist auf jeden Fall ärgerlich...

----------

## Realmaker

Was hast du denn für einen Rechner?

----------

## nillsen

Kann es evtl auch an einer stark fragmentierten Festplatte liegen ? Ich stelle zumindest fest, das dass Update des Portage Cache von Tag zu Tag langsamer wird (update ca. alle 3 tage)

----------

## ruth

hi,

also da hab ich ja meine eigene theorie....  :Wink: 

ich denke, dass der portage tree mittlerweile zu gross ist, um ihn

ohne datenbank-backend in vernünftiger zeit zu indexieren...

-->> der portage cache gehört in eine db (sic!!!)

nicht schlagen bitte... *grins*

gruss

rootshell

----------

## Realmaker

 *rootshell wrote:*   

> hi,
> 
> also da hab ich ja meine eigene theorie.... 
> 
> ich denke, dass der portage tree mittlerweile zu gross ist, um ihn
> ...

 Meine Rede

Gruss, Max

----------

## stahlsau

 *Quote:*   

> Was hast du denn für einen Rechner?

 

AMD @ 2300MHz, 786ram, A7N8X-deluxe-rev2, ähh...nochwas?  :Smile: 

Normalerweise ging das syncen immer in ca. 5 Minuten, je nachdem wieviel zu updaten war. Jetzt lass ich emerge sync immer über Nacht laufen, weils mir zu blöd ist dabeizusitzen und zu warten  :Wink: 

----------

## amne

 *nillsen wrote:*   

> Kann es evtl auch an einer stark fragmentierten Festplatte liegen ? Ich stelle zumindest fest, das dass Update des Portage Cache von Tag zu Tag langsamer wird (update ca. alle 3 tage)

 

Was für ein Dateisystem und wie viel ist auf der Platte noch frei? Wenn ich mich richtig erinnere sinkt die Performance bei Reiserfs (stark) ab wenn nicht mehr allzuviel (<5-10%) frei ist. Keine Ahnung wie das bei anderen Dateisystem ist - vermutlich aber ähnlich.

----------

## Genone

 *rootshell wrote:*   

> hi,
> 
> also da hab ich ja meine eigene theorie.... 
> 
> ich denke, dass der portage tree mittlerweile zu gross ist, um ihn
> ...

 

Hmm, wenn ich mich an das Format von /etc/portage/modules erinnern könnte würde ich dir jetzt sagen, wie du das anschalten kannst   :Wink: 

----------

## SnorreDev

Den Debug output habe ich auch immer wieder mal. Allerdings ist das beim naechsten Sync verschwunden, und taucht dann nach 1-4 Wochen wieder mal auf. Und das dauert dann auch ewig - egal ob auf meinem Server ( noch ReiserFS ) oder auf der Workstation ( xfs only )

Scheint also nix Filesystemmaessiges zu sein.

----------

## nillsen

 *amne wrote:*   

>  *nillsen wrote:*   Kann es evtl auch an einer stark fragmentierten Festplatte liegen ? Ich stelle zumindest fest, das dass Update des Portage Cache von Tag zu Tag langsamer wird (update ca. alle 3 tage) 
> 
> Was für ein Dateisystem und wie viel ist auf der Platte noch frei? Wenn ich mich richtig erinnere sinkt die Performance bei Reiserfs (stark) ab wenn nicht mehr allzuviel (<5-10%) frei ist. Keine Ahnung wie das bei anderen Dateisystem ist - vermutlich aber ähnlich.

 

```

Filesystem           1K-blocks      Used Available Use% Mounted on

/dev/hda3             29293624  24493276   4800348  84% /

```

Das ganze bei ReiserFS. 84% ist ja wirklich nicht mehr sehr viel. Aber wiklich lange dauert es nicht (ca 5 Minuten für gesamten Sync). Aber am Anfang ging es fixer  :Smile: 

----------

## kswtch

Ich möchte nur mitteilen, dass ich das gleiche "Problem" habe. Auf meiner Workstation habe ich diesen angeblichen Debug Output der nach "Updating Portage Cache" kommt noch nie gesehen. Auf meinem Laptop kommt der allerdings und nimmt wirklich Ewigkeiten in Anspruch. Sehr unangenehm. 

Ich denke es ist bisher noch keine Lösung gefunden, wie man das umgehen oder abstellen kann, oder?

----------

## yeoman

Also für diejenigen, bei denen es vielleicht am Filesystem liegt, hier ein Auszug aus den ReiserFS FAQs:

 *Quote:*   

> Performance is poor, and my disk at 96% full still has free space.
> 
> Once a disk drive gets more than 85% full, the performance starts to suffer unless using a repacker (which isn't implemented yet.) You can probably get away with 92%, but if performance is valued you are making a mistake to keep it any fuller. This is true for almost all filesystems. ReiserFS, because of our packing tails together, pack more data into a given percentage used, but it still is subject to the rules for max recommended percentage used..
> 
>     If you create the whole disk with one copy and then mount it read-only, then you can fully pack it without problem. Please be sure that you copy it from (or tar it from) a reiserfs partition so that files are created in reiserfs readdir order as this will improve performance.

 

Man sollte also tunlichst vermeiden, über die 85% zu geraten! Außerdem sollte man zum Ermitteln des freien Speicherplatzes auf ReiserFS Partitionen df benutzen:

 *Quote:*   

> du says ReiserFS makes space efficiency worse.
> 
> Use df not du, or use "raw" option for du if your du supports that. st_blocks summed up is less accurate than st_size for ReiserFS because we pack tails, and st_blocks rounds numbers up. 
> 
> 

 

Das hier behandelte Portage Problem tritt bei mir übrigens nicht auf  :Very Happy:  , aber ich habe meine Partitionen auch entsprechend großzügig gestaltet.

Gruß,

Martin

----------

## lolli78

 *rootshell wrote:*   

> 
> 
> ich denke, dass der portage tree mittlerweile zu gross ist, um ihn
> 
> ohne datenbank-backend in vernünftiger zeit zu indexieren...
> ...

 

mysql? https://forums.gentoo.org/viewtopic.php?t=175461

lorenz

----------

## ruth

hi,

grossartig....  :Wink:  *freu*

genau sowas hab ich mir gedacht...

vielen dank, speziell an lolli78....

gruss

rootshell

----------

## lolli78

hallo, speziell an rootshell,

noch schneller wird portage, wenn man den baum beschneidet. wer kategorien ausschließt, die er/sie nicht interessiert, tut sich und den rsync-betreibern einen gefallen. mehr dazu hier: https://forums.gentoo.org/viewtopic.php?t=173433

lorenz

----------

