# Gedankenexperiment: portage kleiner und schneller

## l3u

Hallo!

Ich gehe mal davon aus, daß das Thema hier schon öfters angesprochen wurde ... aber ich hab gestern mal folgenden Versuch gemacht: Ich hab den kompletten portage-Tree (ohne distfiles) woanders hinkopiert und folgendes Script drüberlaufen lassen:

```
#!/bin/bash

p="./portage"

for i in `ls $p`; do

  if [ -d "$p/$i" ]; then

    echo ">>> $i"

    for j in `ls $p/$i`; do

      if [ -d "$p/$i/$j" ]; then

        echo "     $j"

        (

          cd "$p/$i"   

          tar -czf "$j.tar.gz" "$j"

          rm -r "$j"

        )

      fi

    done

  fi

done
```

Das macht nichts anderes, als alle Programm-Verzeishnisse in je ein .tar.gz-Archiv zu packen. Die Dateien einzeln zu packen hat keinen Sinn gemacht, da das resultierende Archiv zum Teil größer war, als die Quelldatei (weil die allermeisten Dateien im Portage Tree sehr klein sind).

Wenn man dann noch das metadata-Verzeichnis wegläßt und die metadata.xml-Dateien löscht, kommt folgendes raus:

portage vorher: 443 MB und 127.855 Dateien

portage nachher: 60 MB und 11.190 Dateien (!)

Auspacken läßt sich portage folgendermaßen:

```
#!/bin/bash

p="./portage"

for i in `ls $p`; do

  if [ -d "$p/$i" ]; then

    echo ">>> $i"

    (

      cd "$p/$i"

      for j in `ls *.tar.gz`; do

        echo "     $j"

        tar -xzf "$j"

        rm "$j"

      done

    )

  fi

done
```

Würde es nicht massiv die Gentoo-Server entlasten, wenn man mit diesen gepackten Programmverzeichnissen arbeiten würde? Der Traffic würde doch sicher nachlassen; immerhin nähme der portage Tree nur noch 1/7 des Platzes ein, den er jetzt braucht...

Und würde es einen merge-Vorgang nicht massiv beschleunigen, wenn man den ganzen Metadata-Kram nicht in hunderttausend kleinen Dateien ablegen würde, sondern in einer Datenbank? BerkeleyDB zum Beispiel oder vielleicht sogar SQLite?

Wenn man dann was mergen wollen würde, müßte man nur die Programm-Verzeichnisse entpacken, die für die Installation notwendig sind. Und die könnten dann auch wieder gepackt werden. Die Abhängigkeiten, etc. stehen in der Datenbank (in die man dann auch gleich Beschreibungen, etc. aufnehmen könnte ... so wie das eix macht) und man müßte die Datenbank nur dann updaten, wenn sich bei einem Sync ein Programmpaket ändert. Und falls mal was schiefgeht, kann man ja immernoch die Datenbank "from scratch" generieren.

Nur so ne Idee ;-)

----------

## Romses

Hallo

Ich glaube nicht, dass das die Server entlasten würde...

Immerhin werden per rsync nur wirklich veränderte/neue Dateien übertragen, nicht der gesammte Portage-tree.

wenn man nun die einzelnen teile komprimiert, kann rsync nicht mehr selektieren, ob sich Pakete geändert haben, und muss alles vom Server laden.

Gruß Romses

des weiteren bin ich der Meinung, dass portage schon langsam genug ist

----------

## l3u

Naja, es würden ja auch nur die Programmpakete übertragen, die sich verändert haben ... und die sind ja durch die Kompression auch sehr klein! Und portage würde durch ne Datenbank, die die Abhängigkeiten, etc. speichert, sicher _erheblich_ schneller werden

----------

## Genone

Ungefaehr ebenso altes Thema wie fetch on demand, und ebenso kein Stoff fuer portage-2.x.

----------

## psyqil

 *Libby wrote:*   

> portage vorher: 443 MB und 127.855 Dateien
> 
> portage nachher: 60 MB und 11.190 Dateien (!)

 

```
~ $ df -h|grep portage

/portage.sqfs          25M   25M     0 100% /usr/portage

~ $ mount |grep portage

/portage.sqfs on /usr/portage type squashfs (ro,loop=/dev/loop0)
```

----------

## hoschi

Oh mein Gott, hoffentlich kommen bald ein paar Verbesserungen für Portage - langsam nimmt es überhand   :Rolling Eyes: 

----------

## l3u

@psyquil:  *http://squashfs.sourceforge.net/ wrote:*   

> Squashfs is a compressed read-only filesystem for Linux. Squashfs is intended for general read-only filesystem use, for archival use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed.

 

Schaut echt interessant aus, was du gepostet hast, aber ich check's grad net so 100%ig ;-)

Ich denke mal generell, daß es wirklich viele gute Ansätze gibt, um portage zu verbessern. Man muß sich ja z.B. nur mal die Hammer-Performance von eix anschauen! Und man kann doch sicher, wenn eix die Versionen und Beschreibungen aller Pakete (schnell!) speichern und durchsuchen kann, auch die Abhängigkeiten in einer ähnlichen Datenbank ablegen, um auch die Abhängigkeits-Berechnung vor einem Merge-Vorgang auf den Bruchteil einer Sekunde zu drücken, oder?

Ein weiterer, meiner Meinung nach sehr guter Ansatz ist http://de.gentoo-wiki.com/Portage_mit_cdb_beschleunigen -- das "Updating portage cache" geht, seitdem ich das benutze, erheblich schneller. All sowas ist ja vorhanden... man muß es bloß finden!

Trotz allem bin ich der Meinung, daß portage mittlerweile zu groß (und träge) geworden ist, um Metadaten, etc. immer noch in (wörtlich) 100.000 kleinen Datein zu speichern. Wird denn überhaupt an einer Datenbanklösung gearbeitet?

----------

## BlackEye

 *Libby wrote:*   

> Wird denn überhaupt an einer Datenbanklösung gearbeitet?

 

und was ist mit kleinen Server-Systemen? Willst Du denn immer gleich ne ganze Mega-DB aufsetzen, "nur" weil mal ein paar kleine Portage-Dateien da drin sind? Hat sicherlich alles Vor- sowie Nachteile. Aber eine zusätzliche Datenbank bringt:

a) zusätzliche Sicherheitsrisiken

b) zusätzlichen Administrationsaufwand, um a) so gering wie möglich zu halten

c) zusätzlich nötige Ressourcen (Prozessor, Speicher, HDD, etc...)

d) Aus Punkt a-c ergibt sich die Ausgrenzung kleinerer minimalistischere Server. Beispielsweise ne schwache Kiste, die nur als Router fungiert und vielleicht noch nen Proxy drauf laufen hat

e) keine Ahnung was noch für Punkte kommen, wenn man mal betrachtet, dass Gentoo nicht nur für das x86-er System zu haben ist. AMD64, PPC usw.. muss ja alles generisch sein und überall funktionieren...

Vielleicht sollte man Portage modularisierter aufbauen. So, dass man als Administrator die Möglichkeit hat, zu wählen, welches Backend man benutzen möchte. Vorstellen könnte ich mir dabei auch eine art Portage-Server, der einem unter seiner Kontrolle stehendem Netz einen ständig aktuellen Portage-Tree zur Verfügung stellen würde und alle Suchanfragen anderer im Netz befindliche Gentoo-Rechner zu diesem Portage-Server delegiert werden könnten. Entlastet die einzelne Maschine und würde rechenintensive Prozesse einem eigens dafür geschaffenen Server überlassen. Vielleicht gibts das sogar schon, hab mich damit noch nicht tiefergehend befasst. Hab nur eben runtergetippt, was mir so eingefallen ist  :Smile: 

----------

## rojaro

Moin,

es muss ja nicht gleich eine "Mega-DB" sein. Ein kleines Datenbanksystem wie z.B. sqlite sollte den Job machen - das würde viele Dinge beschleunigen und vereinfachen. Eine Datenbank die die package informationen (useflags, dependencies etc.) enthält und die ebuilds, patches etc. in komprimierter form. Das würde sicherlich einiges an Performancesteigerung mit sich bringen und mit Sicherheit einiges an Plattenplatz sparen.

- rojaro -

----------

## BlackEye

also wenn, dann würde ich mir überlegen nicht gleich das System so aufzubauen, dass man die Wahl hat, wie man es gern haben möchte. Eine Wahl für ein Backend und Portage so modularisiert, dass neue Module die Möglichkeiten expandieren, das wäre sicherlich auch für Administratoren größerer Netze interessant

----------

## ChrisM87

Hi,

sagt mal, täuscht es, oder ist emerge --sync nochmals langsamer geworden? (nach der Einführung der Indexes vor einigen Wochen)

Wenn nicht wenigstens Hoffnung in Sicht ist, muss ich wohl auf den alten Maschinen hier was anderes installieren, sonst dauert das wöchentliche Sync bald länger als das Compilieren der Updates danach.

ChrisM

----------

## BlackEye

siehe auch https://forums.gentoo.org/viewtopic-t-385008.html

Die Erfahrung hab ich auch gemacht. Gibt ein paar Ansätze, die dieses Problem mittelfristig beheben oder verbessern, aber langfristig muss doch irgendwas passieren

BTW: Wenn Du nen Server hast, der eh nicht alles im Portage braucht (X, office usw...), dann kannst Du beim sync auch ganze Portage-Zweige ausblenden (Stichwort: RSYNC_EXCLUDEFROM)

----------

## Anarcho

Also ich hab mit dem normalen Portage überhaupt keine Probleme.

Mein Home-server synct eh nur Nachts und da ist mir das total egal ob das nun 3 min oder 3 Stunden braucht. Dieser verteilt das dann via NFS an die Clients und somit haben diese fast keinen aufwand. 

Einzig die Abhängigkeitsberechnung könnte besser werden.

----------

## l3u

Ich würde die ebuilds nicht in einer Datenbank speichern. Das System mit den Dateien find ich gut ... nur würde ich eben (wie oben ausprobiert) für je ein Programm ein .tar.gz-Archiv anlegen. Man müßte doch gar keine SQL-Datenbank benutzen, um Abhängigkeiten zu indizieren. Dafür könnt mir durchaus eine Lösung mit einer BerkeleyDB vorstellen! Die ist sowieso auf dem System verfügbar (bzw. nur eine winzige Abhängigkeit) und sehr schnell.

----------

## BlackEye

 *Libby wrote:*   

> nur würde ich eben (wie oben ausprobiert) für je ein Programm ein .tar.gz-Archiv anlegen

 

Was machst Du eigentlich bei einer Suche oder gar Volltext-Suche? Alles zur Laufzeit wieder auspacken und parsen? Ich sehe schon die nächsten darauffolgenden Threads mit Performanceeinbrüchen  :Smile: 

----------

## l3u

eix benutzen.

----------

## BlackEye

und das ist dann eine Art DB oder wie? Also eine One-File-DB a la sqlite?

----------

## Arudil

thema fetch-on-demand:

darf man sich das so vorstellen, dass bei einem "emerge foobar" immer nur die foo-bardateien (d.h. ebuilds) runtergeladen werden, womit die "überflüssige" ansammlung von ebuilds entfällt?

Gibts da schon konkrete Konzepte, ob das irgendwann eingebaut wird?

----------

## BlackEye

mit fetch on demand meint er den --sync-Vorgang. Es werden nur die ebuilds geladen, die sich zu Deinem lokalen Portage geändert haben. Das wird bereits aktuell so gemacht, weil dies das Arbeitsprinzip von rsync ist

----------

## Genone

 *BlackEye wrote:*   

> mit fetch on demand meint er den --sync-Vorgang. Es werden nur die ebuilds geladen, die sich zu Deinem lokalen Portage geändert haben. Das wird bereits aktuell so gemacht, weil dies das Arbeitsprinzip von rsync ist

 

Nein, die ursprüngliche Annahme war vom Konzept her schon ganz richtig. Konkrete Pläne dazu gibts noch nicht ausser dass das frühestens mit portage-3.x was wird.

----------

## BlackEye

 *Genone wrote:*   

> Nein, die ursprüngliche Annahme war vom Konzept her schon ganz richtig. Konkrete Pläne dazu gibts noch nicht ausser dass das frühestens mit portage-3.x was wird.

 

War mir nicht bekannt, dass es soetwas gibt. Nun, wieder etwas dazugelernt

----------

## Genone

 *BlackEye wrote:*   

>  *Genone wrote:*   Nein, die ursprüngliche Annahme war vom Konzept her schon ganz richtig. Konkrete Pläne dazu gibts noch nicht ausser dass das frühestens mit portage-3.x was wird. 
> 
> War mir nicht bekannt, dass es soetwas gibt. Nun, wieder etwas dazugelernt

 

Gibts ja auch noch nicht   :Wink: 

----------

## slick

Ich habs mal mit dem "Tunen" des Dateisystems probiert. Ich habe hier ein normales ext3, normalerweise sind da ja die Blocks 4KByte groß was für die kleinen ebuilds etwas übertrieben ist. Also lege ich ein loopfile an, erzeuge ein Dateisystem darauf mit sehr kleinen Blöcken und mounte dieses als /usr/portage. Ersparnis ~40% und dabei kann es ganz normal gelesen und beschrieben werden (nicht wie bei ReadOnly-Dateisystemen). Macht man dies auch bei /var/cache/edb sollte das min. (geschätzte) 300 MB an Platz auf der Platte sparen. Ob es allerdings performanter ist kann ich nicht sagen.

Loopfile 250 MB erzeugen

```
# dd if=/dev/zero of=/loopfile bs=1M count=1 seek=250
```

Dateisystem erzeugen

```
# mke2fs -b 1024 -i 1024 /loopfile
```

mounten

```
# mount -o loop,noatime /loopfile /mnt/test/
```

portagetree rüber kopieren

```
# cp -av /usr/portage/* /mnt/test
```

Vergleich: Größe normal

```
# du -sh /usr/portage/

530M    /usr/portage/
```

Vergleich: Größe auf loopfile

```
# du -sh /mnt/test

185M    /mnt/test/
```

Zu beachten ist allerdings dass das Loopfile ~250 MB auf der Platte belegt, da es ja nicht zu 100% mit Daten gefüllt ist. Dennoch eine ziemliche Ersparnis allein durch die richtige Wahl des Dateisystems, u.U. läßt sich mit anderen welche kleines Blockgrößen unterstützen noch mehr herrauskitzeln

----------

## Vaarsuvius

 *slick wrote:*   

> Zu beachten ist allerdings dass das Loopfile ~250 MB auf der Platte belegt, da es ja nicht zu 100% mit Daten gefüllt ist. Dennoch eine ziemliche Ersparnis allein durch die richtige Wahl des Dateisystems, u.U. läßt sich mit anderen welche kleines Blockgrößen unterstützen noch mehr herrauskitzeln

 

also ich hab den spass jetzt mal mit xfs und ner blockgroesse von 512 ausprobiert.

```
# du -sh /usr/portage

531M    /usr/portage
```

```
# du -sh /mnt/test/

143M    /mnt/test/
```

----------

## l3u

... wobei das ja alles "nur" Platz spart und nicht portage schneller macht ...

----------

## psyqil

 *Libby wrote:*   

> @psyquil:  *http://squashfs.sourceforge.net/ wrote:*   Squashfs is a compressed read-only filesystem for Linux. Squashfs is intended for general read-only filesystem use, for archival use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed. 
> 
> Schaut echt interessant aus, was du gepostet hast, aber ich check's grad net so 100%ig 

 Näh, wie die Zeit vergeht... schon wieder ein Jahr rum? Aber den Fortschritt kann man nunmal nicht aufhalten:

https://forums.gentoo.org/viewtopic-p-3500729.html#3500729

```
# time fes.sh

=== Mounting unionfs: done.

 * Removing old portage-cache in /var/cache/edb/dep/* ...                                                                        [ ok ]

 * Running emerge --sync ...                                                                                                     [ ok ]

 * Copying old /var/cache/eix cache to /var/cache/eix.previous ...                                                               [ ok ]

 * Running update-eix ...                                                                                                        [ ok ]

Diffing databases (11499 - 11508 packages)

[hier kommt der diff-eix output]

=== Updating portage tree: syncing...

Parallel mksquashfs: Using 1 processor

Creating little endian 3.0 filesystem on /var/tmp/portage-2006-10-23.sqfs, block size 65536.

Little endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments

Filesystem size 40721.90 Kbytes (39.77 Mbytes)

        25.18% of uncompressed filesystem size (161729.06 Kbytes)

Inode table size 1630196 bytes (1591.99 Kbytes)

        34.80% of uncompressed inode table size (4685025 bytes)

Directory table size 1414943 bytes (1381.78 Kbytes)

        40.10% of uncompressed directory table size (3528807 bytes)

Number of duplicate files found 13056

Number of inodes 149315

Number of files 125420

Number of fragments 2432

Number of symbolic links  0

Number of device nodes 0

Number of fifo nodes 0

Number of socket nodes 0

Number of directories 23895

Number of uids 1

        root (0)

Number of gids 0

done.

=== Umounting unionfs /usr/portage: done.

=== Remounting squashfs /usr/portage: done.

real    1m38.898s

user    0m36.962s

sys     0m26.371s

# ll -Lh /var/tmp/portage.sqfs

-rwx------ 1 root root 40M Oct 23 14:35 /var/tmp/portage.sqfs
```

Und das schönste ist, das die Festplatte nicht so getreßt wird! Ich find's super!  :Very Happy: Last edited by psyqil on Thu Nov 02, 2006 8:40 pm; edited 1 time in total

----------

## Fauli

Wenn einem das Metadata-Update zu lange dauert, kann man es auch ganz abstellen. In der Manpage von portage ist unter /etc/portage/modules erklärt, wie das geht.

```
# du -sh /var/cache/edb/dep/usr/portage

1,0K    /var/cache/edb/dep/usr/portage
```

----------

