View previous topic :: View next topic |
Author |
Message |
tux264 n00b
Joined: 03 Jan 2008 Posts: 10
|
Posted: Thu Jan 03, 2008 11:36 pm Post subject: Hoher Platzverbrauch einer Neuinstallation? |
|
|
Hallo,
ich habe nach langer Debian-Nutzung nun meine erste Gentoo-Installation hinter mich gebracht 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 |
|
Back to top |
|
|
69719 l33t
Joined: 20 Sep 2004 Posts: 865
|
Posted: Fri Jan 04, 2008 1:06 am Post subject: |
|
|
Was sagt den...
Code: |
eval $(emerge --info | grep 'DISTDIR='); du -hsc $DISTDIR/*
|
Dort liegen alle Quelltexte der Pakete die heruntergeladen wurden um sie zu installieren. |
|
Back to top |
|
|
tux264 n00b
Joined: 03 Jan 2008 Posts: 10
|
Posted: Fri Jan 04, 2008 1:15 am Post subject: |
|
|
Quote: | Was sagt den...
Code: |
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 |
|
Back to top |
|
|
69719 l33t
Joined: 20 Sep 2004 Posts: 865
|
Posted: Fri Jan 04, 2008 2:23 am Post subject: |
|
|
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). |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Fri Jan 04, 2008 4:13 am Post subject: Re: Hoher Platzverbrauch einer Neuinstallation? |
|
|
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. |
|
Back to top |
|
|
ManfredB Veteran
Joined: 27 Dec 2007 Posts: 1609
|
Posted: Fri Jan 04, 2008 6:51 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9527 Location: beyond the rim
|
Posted: Fri Jan 04, 2008 7:33 am Post subject: Re: Hoher Platzverbrauch einer Neuinstallation? |
|
|
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. |
|
Back to top |
|
|
treor Apprentice
Joined: 03 May 2005 Posts: 174 Location: germany
|
Posted: Fri Jan 04, 2008 10:00 am Post subject: |
|
|
gutes beispiel:
hab grad distfiles und /var/tmp/portage geleert... 4 gb |
|
Back to top |
|
|
tux264 n00b
Joined: 03 Jan 2008 Posts: 10
|
Posted: Fri Jan 04, 2008 2:25 pm Post subject: |
|
|
Quote: | Kurz und knapp: Gentoo braucht bei normaler Installation mehr Platz als andere Distributionen |
Okay, das wollte ich eigentlich hören 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 |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Jan 04, 2008 3:28 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Fri Jan 04, 2008 8:51 pm Post subject: |
|
|
Danke, Du hast mich auf eine Idee gebracht - bisher habe ich nur /usr/portage derart komprimiert, nicht /usr/src. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Jan 04, 2008 9:21 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Fri Jan 04, 2008 9:43 pm Post subject: |
|
|
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? _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Sat Jan 05, 2008 12:06 am Post subject: |
|
|
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.... |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 05, 2008 8:06 am Post subject: |
|
|
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. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Sat Jan 05, 2008 8:25 am Post subject: |
|
|
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. |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 05, 2008 8:34 am Post subject: |
|
|
Mach das - inzwischen ist ein recht brauchbares ebuild für aufs im sunrise Overlay. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Jan 05, 2008 11:22 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Jan 05, 2008 11:40 am Post subject: |
|
|
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.
|
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 05, 2008 12:10 pm Post subject: |
|
|
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. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
Finswimmer Bodhisattva
Joined: 02 Sep 2004 Posts: 5467 Location: Langen (Hessen), Germany
|
Posted: Sat Jan 05, 2008 12:21 pm Post subject: |
|
|
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" _________________ Bitte auf Rechtschreibung, korrekte Formatierung und Höflichkeit achten!
Danke |
|
Back to top |
|
|
xraver Veteran
Joined: 20 Aug 2003 Posts: 1083 Location: Halberstadt
|
Posted: Sat Jan 05, 2008 12:32 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 05, 2008 12:36 pm Post subject: |
|
|
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. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 05, 2008 1:01 pm Post subject: |
|
|
Da Du mich neugierig gemacht hast, habe ich selbst getestet:
- Dauer von emerge -Dup world:
Code: | 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:
Code: | 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. _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
69719 l33t
Joined: 20 Sep 2004 Posts: 865
|
Posted: Sat Jan 05, 2008 1:06 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|