# Platzverbrauch von Gentoo

## hoschi

Ich habe hier ein fast nacktes Gentoo 2004.2 (Stage1)

Platzverbrauch:

```

6.3M   /bin

0        /boot

144K   /dev

2.1M   /etc

4.1     /lib

0        /mnt

0        /opt

897M  /proc

7.3     /sbin

0        /sys

0        /tmp

956M   /usr

84M    /var

```

den löwenanteil in usr halten src, portage, share

den löwenanteil in var halten cache, db

müssen die so groß sein?

/usr/portage/distfiles ist beinahe leer (gerade gelöscht und mache gerade ein emerge -u world)

der portage baum verbraucht natürlich einiges (fast 100.000 pakete....)

kann ich irgendwo etwas gewinnen, ist das normal (ich weiß es nicht, aber 1gigabyte hdd verbrauch durch gentoo in diesem zustand ist doch einfach nur krass)?

habe mir da noch nie so groß gedanken gemacht

grüße

----------

## hoschi

ich weiß jetzt das usr schon so groß sein sollte, aber wie sieht es mit /var aus?

----------

## blue.sca

was logst du alles? mein var hat zur zeit 554MB ;)

```
blue blue: su -c "du -h /var --max-depth=1"

Password:

401M    /var/tmp

68M     /var/cache

34M     /var/db

60K     /var/run

8.0K    /var/lock

4.0K    /var/state

28K     /var/spool

1.3M    /var/lib

50M     /var/log

4.0K    /var/empty

554M    /var

```

/var/tmp/portage _sollte_ man löschen können, kannst aber mal auf ne bestätigung warten, bin mir nicht sicher.

ausserdem wird ein gentoo nicht wirklich größer. meins hat jetzt 4.5 GB und ich räume nichts auf und hab etwa 250 Packete installiert.

----------

## psyqil

 *blue.sca wrote:*   

> /var/tmp/portage _sollte_ man löschen können, kannst aber mal auf ne bestätigung warten, bin mir nicht sicher.

 Check!

----------

## blue.sca

danke ;)

----------

## Jtb

meine Tipps: regelmäßig /usr/portage/distfiles leeren (falls man nicht immer wieder diesselben Dateien braucht!)

Auf Programme mit Slots prüfen! Ein paar KDE-Versionen fressen sehr schnell viel Platz (qpkg --dups - gentoolkit) - aber nicht alles gleich löschen..

Einige Source-Verzeichnisse (also z.B. Kernel) mit einem make clean beglücken..

----------

## hoschi

danke,

eine frage, was macht den make clean (bevor ich das benütze...)?

ich habe nur festgestellt das alleine das verzeichnis drivers vom kernel 2.6.8.1 (vanilla) 100mb verbraucht  :Surprised: 

ich hab bisher gar nicht geahnt dass die kernel-sourcen so extrem komprimiert sind, ich hätte mein system schon länger mal genauer erforschen müssen...deswegen hat das kopieren der sourcen immer so lange gedauert *uhiiii*

na ja, besser spät als nie

----------

## _hephaistos_

hallo,

meine meinung zu distfiles ist: solange kein akuter platzmangel herrscht, schon das meiste oben lassen, weil ja auch der traffic für einen selber und die hoster geringer wird (siehe auch deltup).

ich finde, auch das gehört berücksichtigt...

eines der wichtigsten dirs, welches nicht gelöscht werden sollte (probiert es ruhig  :Smile: ) ist: /var/db/pkg

hth,

ciao

----------

## Jtb

 *hoschi wrote:*   

> danke,
> 
> eine frage, was macht den make clean (bevor ich das benütze...)?
> 
> 

 

aus der Kernel-Makefile:

 *Quote:*   

> 
> 
> # clean - Delete most, but leave enough to build external modules
> 
> 

 

d.h. es werden Build-Resultate gelöscht - wenn du deinen Kernel neu bauen willst, musst du mehr kompilieren..

Extremer: make mrproper (# mrproper - Delete all generated files, including .config)

Damit löschst du wesentlich mehr - du musst sogar deine config neu machen..

Noch extremer: make distclean

Du bekommst quasi den Anfangsstatus zurück..

Wenn du mehr wissen willst, dann guck mal in die Makefile rein!

btw: bei mir (linux-2.6.8-gentoo-r3) ist mein Kernel-Dir 304 MB groß - nach einem make clean sind noch 237 MB da. Nach einem make mrproper 223 MB..

----------

## Genone

/var/cache/edb und /var/db/pkg brauchen schon einigen Platz (je nach Dateisystem, ebenso wie /usr/portage (auch wenns nur ca. 7000 Pakete mit insgesamt knapp 100.000 Dateien sind  :Wink: . Das Hauptproblem ist schlichtweg Dateisystemoverhead, die meisten Dateien sind < 4 kb was die Standardblockgrösse bei den meisten Dateisystemen ist (heisst: soviel Platz belegt die Datei auf jeden Fall). Wer Lust hat kann ja mal ein kompromiertes Loopback Dateisystem für /usr/portage ausprobieren, sollte einiges an Platzersparnis bringen.

Im Übrigen kann man unerwünschte Pakete (or Kategorien) mit RSYNC_EXCLUDEFROM recht einfach aus dem Tree rauswerfen.

----------

## Fauli

 *Genone wrote:*   

> Das Hauptproblem ist schlichtweg Dateisystemoverhead, die meisten Dateien sind < 4 kb was die Standardblockgrösse bei den meisten Dateisystemen ist (heisst: soviel Platz belegt die Datei auf jeden Fall).

 

Reiserfs kann (ohne notail-Option) mehrere kleine Dateien in einen Block packen. Das kostet natürlich auch Performance.

----------

## hoschi

 *hephaistos6 wrote:*   

> hallo,
> 
> meine meinung zu distfiles ist: solange kein akuter platzmangel herrscht, schon das meiste oben lassen, weil ja auch der traffic für einen selber und die hoster geringer wird (siehe auch deltup).
> 
> ich finde, auch das gehört berücksichtigt...
> ...

 

meine package database mag ich aber...

danke nochmal jungs, besonders für die make clean usw. erklärung ich hab nur über "make clean" selber was erfahren können, nicht über den rest  :Smile: 

und wieder weiß ich ein wenig mehr :O

----------

## Shadows

 *hoschi wrote:*   

> Ich habe hier ein fast nacktes Gentoo 2004.2 (Stage1)
> 
> Platzverbrauch:
> 
> ```
> ...

 

Ähm - warum ist Dein /proc  897M groß?  :Shocked: 

Greetz

Shad

----------

## Jtb

 *Shadows wrote:*   

>  *hoschi wrote:*   Ich habe hier ein fast nacktes Gentoo 2004.2 (Stage1)
> 
> Platzverbrauch:
> 
> ```
> ...

 

weil in /proc keine "echten" Dateien liegen.. Alle Dateien dort liegen nicht auf der Platte.

Die Größe erklärt sich ganz leicht, wenn man bedenkt, dass der RAM-Speicher dort als File abgebildet ist.

----------

## sirro

 *Genone wrote:*   

> Wer Lust hat kann ja mal ein kompromiertes Loopback Dateisystem für /usr/portage ausprobieren, sollte einiges an Platzersparnis bringen.

 

Eigentlich eine gute Idee, aber AFAIK koennen weder cloop noch gcloop sowas rw mounten. Die haben immer nur Readonly-Support.

https://forums.gentoo.org/viewtopic.php?p=1258193#1258193

----------

## py-ro

Hi,

resier4 kann kleinere dateien zusammenfassen, nur wer möchte das jetzt schon nutzen.

MfG

Py

----------

## sirro

 *py-ro wrote:*   

> resier4 kann kleinere dateien zusammenfassen, nur wer möchte das jetzt schon nutzen.

 

Das alte reiserfs konnte das doch auch, oder?! Die Option "notail" habe ich zumindest immer benutzt um genau das auszuschalten um die Geschwindigkeit zu verbessern.  :Wink: 

Wie wäre es mit einer eigenen Portage-Partition (evtl. loopback auf ein image) mit reiserfs-dateisystem und tail angeschaltet...

----------

## py-ro

AFAIK speichert resier3 doch nur dateienden in den Baum aber keine kompletten Dateien, oder belehrt mich jemand eines besseren?

----------

## Jtb

 *sirro wrote:*   

>  *py-ro wrote:*   resier4 kann kleinere dateien zusammenfassen, nur wer möchte das jetzt schon nutzen. 
> 
> Das alte reiserfs konnte das doch auch, oder?! Die Option "notail" habe ich zumindest immer benutzt um genau das auszuschalten um die Geschwindigkeit zu verbessern. 
> 
> Wie wäre es mit einer eigenen Portage-Partition (evtl. loopback auf ein image) mit reiserfs-dateisystem und tail angeschaltet...

 

Damit würdest du jeden Gentoo-User zwingen ReiserFS zu nutzen...

Selber bauen kannst du ja immer  :Wink: 

btw: bei ext2/3 könnte man doch auch einfach das Verhältnis Inode/Byte ändern...

----------

## Shadows

 *Jtb wrote:*   

> weil in /proc keine "echten" Dateien liegen.. Alle Dateien dort liegen nicht auf der Platte.
> 
> Die Größe erklärt sich ganz leicht, wenn man bedenkt, dass der RAM-Speicher dort als File abgebildet ist.

 

Ja, gerade weil /proc on-the-fly erzeugt wird hatte ich mich da auch drüber gewundert - dass in /proc/kcore der gesamte RAM abgebildet wird wusste ich allerdings nicht - ist das neu mit 2.6.x gekommen oder war das mit 2.4.x auch schon so? Glaub ich schon fast nicht, dass ich das bisher nicht gemerkt habe  :Embarassed: 

Greetz

Shad

----------

## Jtb

 *Shadows wrote:*   

>  *Jtb wrote:*   weil in /proc keine "echten" Dateien liegen.. Alle Dateien dort liegen nicht auf der Platte.
> 
> Die Größe erklärt sich ganz leicht, wenn man bedenkt, dass der RAM-Speicher dort als File abgebildet ist. 
> 
> Ja, gerade weil /proc on-the-fly erzeugt wird hatte ich mich da auch drüber gewundert - dass in /proc/kcore der gesamte RAM abgebildet wird wusste ich allerdings nicht - ist das neu mit 2.6.x gekommen oder war das mit 2.4.x auch schon so? Glaub ich schon fast nicht, dass ich das bisher nicht gemerkt habe 
> ...

 

kcore gibt es schon sehr lange - selbst im "alten" Kernel 2.2 war es mit dabei.. Seit wann es drin ist, kann ich dir aber nicht sagen.

----------

## Shadows

 *py-ro wrote:*   

> AFAIK speichert resier3 doch nur dateienden in den Baum aber keine kompletten Dateien, oder belehrt mich jemand eines besseren?

 

 *man mount wrote:*   

>       notail By  default,  reiserfs stores small files and `file tails' directly into its tree. This confuses
> 
>               some utilities such as LILO(8).  This option is used to disable packing of files into the  tree.

 

 *jtb wrote:*   

> kcore gibt es schon sehr lange - selbst im "alten" Kernel 2.2 war es mit dabei.. Seit wann es drin ist, kann ich dir aber nicht sagen.

 

Kannst Du mir dann auch noch sagen warum das so ist? Ich meine, wofür ist das gut? Wozu kann ich das als Entwickler nutzen und macht das überhaupt Sinn auf einem End-User-System?

Greetz

Shad

----------

## py-ro

Ok, nobody is perfect.   :Wink: 

----------

## Jtb

 *Shadows wrote:*   

>  *py-ro wrote:*   AFAIK speichert resier3 doch nur dateienden in den Baum aber keine kompletten Dateien, oder belehrt mich jemand eines besseren? 
> 
>  *man mount wrote:*         notail By  default,  reiserfs stores small files and `file tails' directly into its tree. This confuses
> 
>               some utilities such as LILO(.  This option is used to disable packing of files into the  tree. 
> ...

 

abseits von cat /proc/kcore > /dev/dsp fehlt mir nichts ein..

Google sagt aber, dass z.B. ein Debugger davon gebrauch machen kann..

----------

## Shadows

 *py-ro wrote:*   

> Ok, nobody is perfect.  

 

Na ja - ich weiß es auch erst seit gestern oder vorgestern, von daher  :Cool: 

@jtb:

k, die Sache mit dem kcore belass ich jetzt erstmal soweit, ist eh OT  :Wink: 

Greetz

Shad

----------

## Genone

 *sirro wrote:*   

>  *Genone wrote:*   Wer Lust hat kann ja mal ein kompromiertes Loopback Dateisystem für /usr/portage ausprobieren, sollte einiges an Platzersparnis bringen. 
> 
> Eigentlich eine gute Idee, aber AFAIK koennen weder cloop noch gcloop sowas rw mounten. Die haben immer nur Readonly-Support.
> 
> https://forums.gentoo.org/viewtopic.php?p=1258193#1258193

 

Naja, portage brauch da ja keinen Schreibzugriff (sofern man PKGDIR und DISTDIR woanders hinpackt, für die macht das ohnehin keinen Sinn), insofern reicht ein readonly Dateisystem ja aus.

----------

## sirro

 *Genone wrote:*   

> Naja, portage brauch da ja keinen Schreibzugriff (sofern man PKGDIR und DISTDIR woanders hinpackt, für die macht das ohnehin keinen Sinn), insofern reicht ein readonly Dateisystem ja aus.

 

Soweit richtig, aber dann muss ich fuer jeden sync (den man ja irgendwann mal macht) wieder ein neues Iso erstellen wofuer ich wieder Plattenplatz brauche. Alternative waere von Zeit zu Zeit auf einem zweiten Rechner das Iso zu erzeugen...

Mein Versuch mit einem reiserfs-iso gemountet brachte mein Portage von 230MB auf 200MB runter. Immerhin 14% ersparnis gegenueber der grossen ext3.

Als naechstes teste ich mal ein readonly-(g)cloop.  :Wink: 

EDIT: Gibts kein tarloop?  :Wink:  65% Ersparnis und nicht so rechenintensiv wie ?zip

----------

## Jtb

 *sirro wrote:*   

>  *Genone wrote:*   Naja, portage brauch da ja keinen Schreibzugriff (sofern man PKGDIR und DISTDIR woanders hinpackt, für die macht das ohnehin keinen Sinn), insofern reicht ein readonly Dateisystem ja aus. 
> 
> Soweit richtig, aber dann muss ich fuer jeden sync (den man ja irgendwann mal macht) wieder ein neues Iso erstellen wofuer ich wieder Plattenplatz brauche. Alternative waere von Zeit zu Zeit auf einem zweiten Rechner das Iso zu erzeugen...
> 
> Mein Versuch mit einem reiserfs-iso gemountet brachte mein Portage von 230MB auf 200MB runter. Immerhin 14% ersparnis gegenueber der grossen ext3.
> ...

 

probier doch mal beim Formatieren mit Ext3 die Werte für Bytes pro Inode und Inodes insgesamt zu ändern..

----------

## sirro

 *Jtb wrote:*   

> probier doch mal beim Formatieren mit Ext3 die Werte für Bytes pro Inode und Inodes insgesamt zu ändern..

 

Sehr guter Tipp, war zwar ein ziehmliches "Geroedel" auf der platte beim Kopieren aber die Ersparnis ist gross => 82 statt 230MB => ca. 65% Ersparnis...

----------

## sirro

Hab das ganze mal auf meinem alten Laptop ausprobiert und die geschwindkeitsverluste ein bisschen geschaetzt.

Bei einem emerge -s test wurde mit der kleinen Blockgroesse 30s statt 10s fuer die Suche gebraucht. emerge -pv xyz war auch meistens merklich langsamer schaetze um den Faktor 2.

Alles in allem (fuer mich) akzeptable Einbussen um 50% des Speicherplatzes fuer Portage zu sparen. (natuerlich gekoppelt mit dem ebenfalls sparenden Rsync-exclude)

----------

