# Hoher Platzverbrauch einer Neuinstallation?

## tux264

Hallo,

ich habe nach langer Debian-Nutzung nun meine erste Gentoo-Installation hinter mich gebracht  :Smile:  Hat mit Hilfe des offiziellen Handbuchs auch sehr gut funktioniert und soweit bin ich auch sehr zufrieden.

Mit ist nur aufgefallen, dass die Installation schon sehr viel Festplattenspeicher verbraucht, nämlich 2070 MB auf / . Das einizige Paket, das ich emerged habe, war distcc, dabei wurden 194 weitere Ports emerged. Meine parallele Debian Installation hab mit komplettem Xorg, fluxbox und jeder Menge Programmen nur 1630 MB.

Liegt der große Platzverbrauch noch im Rahmen, oder habe ich mir schon viel "Müll" eingehandelt? Danke schon mal im Voraus.

Gruß

tux264

----------

## 69719

Was sagt den...

```

eval $(emerge --info | grep 'DISTDIR='); du -hsc $DISTDIR/*

```

Dort liegen alle Quelltexte der Pakete die heruntergeladen wurden um sie zu installieren.

----------

## tux264

 *Quote:*   

> Was sagt den...
> 
> ```
> 
> eval $(emerge --info | grep 'DISTDIR='); du -hsc $DISTDIR/*
> ...

 

Erstmal danke für deine Antwort. 170 MB sind die Quelltexte groß. 

Als USE-Flags verwende ich übrigens zusätzlich zum i686-Standart-Profil: "alsa acpi -apm dvd cdr dvdr gnome gtk -kde -qt3 -qt4 socks5 X"

Gruß

TimmintoR 2°°4

----------

## 69719

Also laut "eix -I" habe ich 834 Pakete installiert und die verwenden alle 6,6 GB inklusive distfiles (2.8 GB).

Da mußte warscheinlich mal mit "du -hsc /" nen bissel suchen.

Eventuell könnte auch noch was in /var/tmp/portage liegen, das könntest du leeren, da dort die Quelltexte übersetzt werden (es sei denn du hast den Pfad geändert).

----------

## musv

 *tux264 wrote:*   

> Mit ist nur aufgefallen, dass die Installation schon sehr viel Festplattenspeicher verbraucht, nämlich 2070 MB auf / . Das einizige Paket, das ich emerged habe, war distcc, dabei wurden 194 weitere Ports emerged. Meine parallele Debian Installation hab mit komplettem Xorg, fluxbox und jeder Menge Programmen nur 1630 MB.
> 
> Liegt der große Platzverbrauch noch im Rahmen, oder habe ich mir schon viel "Müll" eingehandelt? 

 

Je nach Dateisystem braucht allein schon der Portage-Tree auch ohne Distfiles bis zu 600 mb. 

Fehlerhafte halbangefangene compilierte Pakete liegen in /var/tmp/portage, da kann auch schnell was zusammen kommen.

Kernelquellen benötigen auch ihren Platz (>100mb), und die sind bei Binärdistributionen selten installiert

Und wie bereits erwähnt, sind die Archive der Quellcodes in /usr/portage/distfiles auch von beachtlicher Größe

Kurz und knapp: Gentoo braucht bei normaler Installation mehr Platz als andere Distributionen. Je nach Installation und Temp-Müll werden dann auch schon mal 20GB für die Installation knapp.

----------

## ManfredB

Wer OpenOffice braucht und das emergen will,

muss mit sehr viel Platz während des Prozesses rechnen.

Ich habe als Desktop KDE und die Platte war 10 GB gross.

Da hat es mit dem Platz Probleme gegeben, was ich auch

erst nicht glauben wollte, aber die Platte war zu 100 % belegt.

Ob das so stimmt und an OpenOffice liegt, kann ich zwar

nicht sicher behaupten, aber es war das letzte, was über

Nacht durchlief. Am nächsten Vormittag war es fertig

und nach Reboot war die Platte voll, so dass ich mich

nicht einmal mehr auf Konsole einloggen konnte.

Gruss

Manfred

P.S. meine jetzige Platte (Partition) ist 15 GB gross,

davon sind im Moment (ohne OpenOffice) 28 % belegt.

----------

## Genone

 *tux264 wrote:*   

> Mit ist nur aufgefallen, dass die Installation schon sehr viel Festplattenspeicher verbraucht, nämlich 2070 MB auf / . Das einizige Paket, das ich emerged habe, war distcc, dabei wurden 194 weitere Ports emerged.

 

Wobei durch USE Flags vermutlich schon X, GTK und diverse andere Dinge mitinstalliert wurden.

----------

## treor

gutes beispiel:

hab grad distfiles und /var/tmp/portage geleert... 4 gb  :Wink: 

----------

## tux264

 *Quote:*   

> Kurz und knapp: Gentoo braucht bei normaler Installation mehr Platz als andere Distributionen

 

Okay, das wollte ich eigentlich hören  :Smile:  Wenn ich die 650 MB des Portage-Trees abziehe bin ich wieder auf dem Niveau der Debian-Installation. 

 *Quote:*   

> Wobei durch USE Flags vermutlich schon X, GTK und diverse andere Dinge mitinstalliert wurden.

 

Ja, viele Bibliotheken von X, Gnome und GTK sind natürlich auch mitinstalliert worden. 

Nochmals danke an alle

Gruß

tux264

----------

## mv

 *musv wrote:*   

> Kurz und knapp: Gentoo braucht bei normaler Installation mehr Platz als andere Distributionen

 

Wenn es mit dem Plattenplatz knapp wird, empfiehlt sich die Benutzung von squashfs+aufs/unionfs:

 *Quote:*   

> 1. Je nach Dateisystem braucht allein schon der Portage-Tree auch ohne Distfiles bis zu 600 mb.

 

Mit squashfs (sowie zusätzlich dem Filtern einiger nicht-benötigter Zweige, was aber kaum etwas ausmacht)

sind es hier gerade mal 40 MB.

 *Quote:*   

> 3. Kernelquellen benötigen auch ihren Platz (>100mb), und die sind bei Binärdistributionen selten installiert

 

Normalerweise wesentlich mehr: Um die 250MB. Und noch einmal zusätzlich 100MB für die beim Kernel-Compilieren erzeugten Files (KBUILD_OUTPUT). Mit squashfs+aufs/unionfs alles zusammen: 86MB.

Nicht zu vergessen: /var/db, das auch nochmal von (je nach Filesystem und installierten Paketen) 90-150MB auf ca. 50 MB schrumpft.

Zwar weiß ich nicht, was die Debian-Paketverwaltung intern an Daten speichert, aber zumindest im Vergleich mit rpm-Distributionen, bei der die Datenbank auch etliche MB schluckt, schneidet Gentoo da gar nicht so schlecht ab. Wenn man dann noch bedenkt, dass man aufgrund von USE-Flags i.d.R. deutlich weniger Pakete installiert hat... Klar, die Files in distdir und so viel Temporärspeicher z.B. zum openoffice-kompilieren brauchen andere Distributionen natürlich nicht.

----------

## schachti

Danke, Du hast mich auf eine Idee gebracht - bisher habe ich nur /usr/portage derart komprimiert, nicht /usr/src.

----------

## mv

 *schachti wrote:*   

> bisher habe ich nur /usr/portage derart komprimiert, nicht /usr/src.

 

Das solltest Du aber nur tun, wenn Du mit KBUILD_OUTPUT arbeitest (wurde gerade in Kernel-Konfigurationsthread diskutiert). Wenn nämlich das unionfs/aufs-Modul (noch) nicht geht, kannst Du den Kernel-Baum dann nicht beschreiben (obwohl als Notlösung natürlich immer unsquashfs hilft).

----------

## schachti

Ich verstehe das Problem nicht. Derzeit habe ich ein funktionierendes System, mit dem aufs läuft. Wenn ich den Kernel neu baue, wird vor dem Reboot auf aufs neu gebaut. Was soll da schiefgehen?

----------

## Klaus Meier

 *schachti wrote:*   

> Danke, Du hast mich auf eine Idee gebracht - bisher habe ich nur /usr/portage derart komprimiert, nicht /usr/src.

 

Ah ja, wie war das doch noch gleich mit den Kosten für 2G Festplattenspeicher.... Und jetzt machst dir Streß wegen 100 MB....

----------

## schachti

Nicht wegen der Kosten, sondern wegen der Geschwindigkeit - /usr/portage enthält über 100.000 Dateien und belegt unkomprimiert so um die 600 MB (bei ext3). Durch den Trick mit squashfs+aufs wird der Speicherbedarf auf unter 50 MB reduziert, was alle emerge-Vorgänge etc. deutlich beschleunigt - gerade ein emerge --sync ist deutlich schneller, ebenso emerge -s und emerge -S. Ich tue das nicht wegen ein paar hundert MB, sondern wegen der Geschwindigkeit.

----------

## Klaus Meier

 *schachti wrote:*   

> Nicht wegen der Kosten, sondern wegen der Geschwindigkeit - /usr/portage enthält über 100.000 Dateien und belegt unkomprimiert so um die 600 MB (bei ext3). Durch den Trick mit squashfs+aufs wird der Speicherbedarf auf unter 50 MB reduziert, was alle emerge-Vorgänge etc. deutlich beschleunigt - gerade ein emerge --sync ist deutlich schneller, ebenso emerge -s und emerge -S. Ich tue das nicht wegen ein paar hundert MB, sondern wegen der Geschwindigkeit.

 

Oh, danke, da hat so ein Spruch doch mal was gebracht, werde ich mir mal ansehen.

----------

## schachti

Mach das - inzwischen ist ein recht brauchbares ebuild für aufs im sunrise Overlay.

----------

## mv

 *schachti wrote:*   

> Ich verstehe das Problem nicht. Derzeit habe ich ein funktionierendes System, mit dem aufs läuft. Wenn ich den Kernel neu baue, wird vor dem Reboot auf aufs neu gebaut. Was soll da schiefgehen?

 

Viel kann nicht schiefgehen, aber man sollte sich der Henne-Ei-Problematik bei der Sache bewusst sein. Beispielsweise, wenn Du das Neubauen mal vergisst. Oder ein Stromausfall kommt. Oder wenn aufs mit dem neuen Kernel einfach nicht will. Ist aber auch meistens kein Problem, weil zum Neubauen eines Moduls über ein vernünftiges Ebuild nur nach /var/tmp/portage geschrieben wird.

Andererseits hatte ich z.B. unlängst das Problem, dass ich squashfs-3.3 benutzt hatte, ohne zu wissen, dass das der Gentoo-Kernel damit (noch) nicht klar kommt - da half wirklich nur unsquashfs.

----------

## mv

 *Klaus Meier wrote:*   

> Ah ja, wie war das doch noch gleich mit den Kosten für 2G Festplattenspeicher.... Und jetzt machst dir Streß wegen 100 MB....

 

Bei einem Laptop sind die Kosten nicht ganz so gering. Und auch bei anderen Rechnern möchte man vielleicht nicht unbedingt eine neue Festplatte einbauen, wenn es die alte noch "knapp" tun könnte. Ein anderer Grund wurde ja schon genannt.

Hier sind noch ein paar weitere:

 Man sieht sofort, ob etwas auf das betreffende Directory geschrieben hat (so kann man z.B. buggy Ebuilds von Kernel-Modulen entlarven, die eben nicht in das Kernel-Directory schreiben sollten).

 Beim Portage-Baum hat man noch ein read-only Backup, ohne dieses vorher manuell anzulegen. Wenn eix-sync z.B. anzeigt, dass ein wichtiges Paket aus dem Portage-Baum entfernt wurde, kann man dieses manuell gleich in sein Overlay kopieren. Oder wenn ein Update eines Pakets nicht klappt, die vorherige Version aber gleich aus dem Baum entfernt wurde, hat man da auch nochmals Zugriff darauf (und kann sich auch bequem die Änderungen am ebuild anschauen).

 Das squashfs-File der Kernel-Sourcen oder des Portage-Baums auf einen anderen Rechner (z.B. Laptop) zu kopieren geht um ein Vielfaches schneller als Kopieren mit rsync bzw. emergen der Kernel-Sourcen.

 Man kann in den mit squashfs+aufs behandelten Directories "mal schnell" ein paar Änderungen machen (z.B. in /var/db beim Experimentieren im Fall von irgendwelchen Kollisionen o.ä. oder in /usr/share/texmf-* beim Kompilieren einer TeX-Anleitung) und diese nachher durch ein einziges Kommando rückgängig machen.

----------

## schachti

 *mv wrote:*   

> Viel kann nicht schiefgehen, aber man sollte sich der Henne-Ei-Problematik bei der Sache bewusst sein. Beispielsweise, wenn Du das Neubauen mal vergisst. Oder ein Stromausfall kommt. Oder wenn aufs mit dem neuen Kernel einfach nicht will.

 

Naja, in all diesen Fällen habe ich ja noch den alten Kernel mit dem dafür funktionierenden alten Modul. Ich behalte bei jedem Kernel-Update immer die letzten 1-2 funktionstüchtigen Kernel als Fallback, falls mal was schiefgeht (muß ja nicht unbedingt aufs sein, sondern irgendeine beliebige Änderung im Kernel).

 *mv wrote:*   

> Andererseits hatte ich z.B. unlängst das Problem, dass ich squashfs-3.3 benutzt hatte, ohne zu wissen, dass das der Gentoo-Kernel damit (noch) nicht klar kommt - da half wirklich nur unsquashfs.

 

Das Problem hatte ich, dafür habe ich auch einen Bugreport auf b.g.o aufgemacht. Ist aber auch alles kein Problem, notfalls macht man ein emerge --sync und überträgt den kompletten portage tree neu (dann ist es egal, ob squashfs+aufs für /usr/portage geht oder nicht) bzw. installiert die Kernel-Quellen einfach neu. Von daher denke ich nicht, dass bei einer Einschränkung auf /usr/portage und /usr/src viel schiefgehen kann.

----------

## Finswimmer

Moved from Deutsches Forum (German) to Diskussionsforum.

Ist kein Supportproblem im klassischen Sinn, da Gentoo so funktioniert, wie es soll. Zudem geht es nun sehr in Richtung "Wie minimiere ich den Portage Tree"

----------

## xraver

Eigentlich bin ich mit dem PortageTree selber zufrieden. Da einzige was mich nach längerer Zeit nun sehr stört, das das berechnen von dependencies wie z.b emerge $foo_bar -pv sehr lange dauert. Am Anfang gings schneller, aber nun dauert es ewig.

Bei einem emerge system -upv oder gar world dauert es noch länger.

Nun lese ich hier was vom squashfs und die Performance.

Kann ich davon ausgehen, das bei Benutzung von sqash-fs die Geschwindigkeit wieder erträglich wird?

Desweiteren würde mich auch interessieren warum die Berechnungen nun bedeutend länger dauern als bei einer Neuinstallation.

----------

## schachti

 *xraver wrote:*   

> Nun lese ich hier was vom squashfs und die Performance.
> 
> Kann ich davon ausgehen, das bei Benutzung von sqash-fs die Geschwindigkeit wieder erträglich wird?

 

Zumindest subjektiv ist es bei mir dadurch deutlich schneller geworden - tatsächlich gemessen habe ich nicht, ob und wieweit ein emerge -Dup world dadurch beschleunigt wird. Da sich das ganze aber relativ leicht installieren läßt, kannst Du es ja einfach selbst mal ausprobieren.

 *xraver wrote:*   

> Desweiteren würde mich auch interessieren warum die Berechnungen nun bedeutend länger dauern als bei einer Neuinstallation.

 

Vermutlich liegt es unter anderem daran, dass Du nach und nach mehr installiert hast. Rein intuitiv würde ich vermuten, dass die benötigte Zeit mindestens linear mit der Anzahl der installierten Pakete steigt.

----------

## schachti

Da Du mich neugierig gemacht hast, habe ich selbst getestet: 

Dauer von emerge -Dup world:

```
sync && echo 3 > /proc/sys/vm/drop_caches && time emerge -Dup world && time emerge -Dup world
```

ohne squashfs+aufs: ungecached 1:07 Minuten, gecached 0:11 Minuten

mit squashfs+aufs: ungecached 0:23 Minuten, 0:11 Minuten

Dauer von emerge -S:

```
sync && echo 3 > /proc/sys/vm/drop_caches && time emerge -S eps && time emerge -S eps
```

ohne squashfs+aufs: ungecached 1:40 Minuten, gecached 0:16 Minuten

mit squashfs+aufs: ungecached 0:38 Minuten, 0:17 Minuten

Zugegebenermaßen keine Laborumgebung (X, Firefox etc. liefen), aber zumindest ein interessanter Anhaltspunkt.

----------

## 69719

 *Klaus Meier wrote:*   

> Man sieht sofort, ob etwas auf das betreffende Directory geschrieben hat (so kann man z.B. buggy Ebuilds von Kernel-Modulen entlarven, die eben nicht in das Kernel-Directory schreiben sollten).
> 
> 

 

Meinest ersachtens schreiben diese Module nicht in das Kernel-Verzeichnis, sondern ins Kernel-Module-Verzeichnis.

Dies sollte ebenfalls sandbox in der FEATURES Option während des Compile Vorgangs verhindern.

----------

## xraver

 *schachti wrote:*   

> Da Du mich neugierig gemacht hast, habe ich selbst getestet: 
> 
> 

 

Danke, du hast mir die Arbeit abgenommen.

War gerade dabei es selber zu testen, wusste aber nicht wie ich den PlattenCache abstellen kann.

Folgendes verwirrte mich

```

time emerge --metadata

>>> Updating Portage cache:  100%

real    1m51.154s

user    0m12.272s

sys     0m5.809s

time emerge --metadata

>>> Updating Portage cache:  100%

real    0m10.148s

user    0m8.880s

sys     0m1.128s

```

Das erste mal ratterte die Platte vor sich hin, das 2te mal hörte ich gar nix. Wieder mal dazu gelernt.

Der gute Cache macht ne Menge aus wie man sehen kann.

Jetzt führ ich mir mal sqashfs zu Gemüte.

Danke für die sehr gute Info.

----------

## schachti

 *xraver wrote:*   

> 
> 
> War gerade dabei es selber zu testen, wusste aber nicht wie ich den PlattenCache abstellen kann.
> 
> 

 

Das habe ich noch nicht mal gemacht (könnte mit der Option -f von hdparm gehen), ich habe mit echo 3 > /proc/sys/vm/drop_caches nur den Cache geleert, den der Kernel verwaltet. Da die meisten gängigen Festplatten intern 1-8 MB, einige wenige 16 MB Cache besitzen, fällt dieser nicht so sehr ins Gewicht (im Vergleich zu den ca. 600 MB, die /usr/portage unkomprimiert auf ext3 belegt).

----------

## mv

 *escor wrote:*   

> Meinest ersachtens schreiben diese Module nicht in das Kernel-Verzeichnis, sondern ins Kernel-Module-Verzeichnis.
> 
> Dies sollte ebenfalls sandbox in der FEATURES Option während des Compile Vorgangs verhindern.

 

Sollte. Aber erstens kann das ebuild das FEATURE abstellen (und gerade buggy 3rd-party ebuilds für Kernel-Module würde ich so etwas zutrauen) und zweitens musste man zuweilen dieses Feature ohnehin abstellen (z.B. das -.gcda-Problem auf amd64 - einer der wohl längsten Bugs auf Gentoo)

----------

## mv

 *xraver wrote:*   

> Das erste mal ratterte die Platte vor sich hin, das 2te mal hörte ich gar nix.

 

Das ist genau das Problem: Es ist nicht die Menge der Daten, die es ausmacht, sondern dass die Daten in lauter einzelne Files verstreut sind, wodurch sich der Lesekopf i.d.R. für jedes einzelne Paket Dutzende Male hin- und herbewegen muss. Die Daten selbst passen locker in den Platten-Cache, wenn man nicht gerade gleichzeitig etwas extrem Speicherhungriges macht.

Noch krasser fällt das auf bei /var/db/pkg: Nach einem Neubooten dauert beispielsweise eix -J gewaltig, weil jedes Directory aus /var/db/pkg/*/* gelesen werden muss. Danach geht es flink. (Da ich /var/db nur mit Cache betreibe, kann ich nur diese Zeiten liefern: Damit ist es konstant ca. 0.6s bei ca. 1100 installierten Paketen).

Edit: Sorry, meine Blödheit. Natürlich muss man CHECK_INSTALLED_OVERLAYS=true setzen (sonst benutzt eix einen Hack und schaut nur bei den wenigsten Paketen tatsächlich nach...): Damit ändert sich die Zeit auch mit squashfs um den Faktor 10: Ca. 6s. (Hier dürfte allerdings die Rechnergeschwindigkeit und ev. auch RAM die Limitierung sein - ist nur ein K6 mit 256kB RAM).

----------

## xraver

Datenbank?

Gut, das es aus Gründen der Kompatibilität und Abhängigkeiten keine DBs benutzt werden kann, leuchtet ein.

Trotzdem würde es mich freuen wenn die Gentoo Hacker mal über den Einsatz von DB´s nachdenken.

Wenigstens als Alternative nachdem man sein System über stage3 hinaus gebaut hat.

Aber das wurde bestimmt schonmal diskutiert.....

Das mit den zig Tausend Files und rsync mag zwar stabiel und in minimalsten Umgebungen einfach funktionieren - trotzdem finde ich die Performance übel.

Und besonders "Festplattenfreundlich" ist die Lösung auch nicht.

Könnte man ja schon fast scherzhaft Wetten;

"Was dauert länger, das rsync oder das aufbauen des Caches  :Wink: ".

----------

## Finswimmer

Aber wie oft machst du das denn alles, dass es schlimm wäre, wenn du mal 10 Sek warten musst...

Ich synce immer am Anfang von einem World-Update --> das dauert dann schon so ewig, dass der Sync keine Rolle spielt.

Parallel dazu wird eix aufgebaut. Daher geht die Suche auch immer schön schnell.

Ich sehe keine Notwendigkeit da irgendwas zu verbessern.

Tobi

----------

## xraver

 *Finswimmer wrote:*   

> Aber wie oft machst du das denn alles, dass es schlimm wäre, wenn du mal 10 Sek warten musst...
> 
> 

 

Wenn es denn mal 10sec währen  :Wink: .

Am meisten nervt es wenn man mal eben schauen will ob ein bestimmtes Programm im PortageTree vorhanden ist oder eben ein update.

Klar, man kann auf andere Sachen wie eix oder der Portage Website ausweichen, aber eix nutz ich nicht weil mir das updaten auch zu lange dauert.

Löst auch nicht das Problem.

Ich will ja portage nicht abschaffen. Finde die Geschichte mit den Files einerseits Praktisch aber wiederum auch sehr lahm.

Naja, sqashfs reicht mir erstmal auch.

----------

## schachti

Wobei man ehrlicherweise sagen muß, dass der Vorteil von Portage via squashfs und aufs nicht so groß ist, wie man auf den ersten Blick vielleicht vermutet. Wenn man emerge mehrmals direkt hintereinander benutzt, hat man keinen Vorteil mehr, nur bei der ersten Benutzung - dafür muß die squashfs Datei nach Änderungen spätestens beim Herunterfahren neu gebaut werden, was auch 20-30 Sekunden dauert (ist bei mir nicht so tragisch, da es beim Herunterfahren automatisch geschieht, aber muß man halt auch einrechnen).

----------

## mv

 *schachti wrote:*   

> Wenn man emerge mehrmals direkt hintereinander benutzt, hat man keinen Vorteil mehr, nur bei der ersten Benutzung

 

Das ist nicht richtig. Es ist egal wie oft man emerge hintereinander benutzt hat - entscheidend ist nur, wieviele Dateien sich geändert haben. Wenn das nicht zu viele sind (und außer in krassen Fällen wie Stabilisierung eines neuen KDE o.ä. ist das innerhalb vernünftiger Zeitspannen nicht der Fall) wird der Vorteil nur leicht geringer. Außerdem kann man natürlich bei Bedarf das Init-Script restarten (solange zu dem Zeitpunkt nichts auf den Portage-Baum zugreift) um schon mal zu komprimieren und anschließend wieder schnellere Zugriffe zu haben...

----------

## schachti

Was ich meinte ist der Effekt, den man in meinem Mini-Benchmark sieht: Zwei Mal hintereinander emerge -S --> beim zweiten Durchlauf hat man keinen Geschwindigkeitsvorteil mehr.

----------

