# [gelöst] 35 GB gentoo-archive benötigt 161.5 GB

## LuxJux

Edit: Thema gekürzt von ( [gelöst] 35 GB gentoo-archive benötigt 161.5 GB auf Festplatte)

Bin ja langsam mit reingewachsen.

Update von 13 auf 17.0-Profil = ok

Update von x-proto = ok

```
emerge @world

Nothing to merge.
```

Und alles läuft.

Nun dachte ich mir: Jetzt wäre der richtige Zeitpunkt das System zu speichern.

Tja, falsch gedacht.

gentoo möchte 161 GB als .tib haben (Benutze seit ewigen Zeiten True-Image, bisher ohne Probleme.)

Heutzutage ist das ja nicht so das Problem. Hab ja hier noch 1,4 TerraByte frei. (Das .tib wurde fehlerfrei gespeichert)

ark ist jetzt grad noch am einpacken, kann deshalb erst morgen was dazu sagen.

 irgendwas stimmt doch hier nichtLast edited by LuxJux on Fri May 11, 2018 6:25 pm; edited 2 times in total

----------

## ChrisJumper

Schau einfach mal wo der Platz verwendet wird. Ich vermute du hast unter /usr/portage/distfiles/ einige Source-Pakete liegen? Dann sind da vielleicht noch einige Git-Clones dabei oder Daten die Nutzer in deinem Home-Verzeichnis angelegt haben. Vielleicht auch einiges im temporären Verzeichnis wo Portage beim Compilieren seine Pakete baut.

wiki.gentoo.org - Remove obsoleted distfiles

----------

## LuxJux

Update:

ark war nicht in der Lage ein gentoo.tar.gz zu erstellen

calculate (36 GB) (/dev/sda5) erstellt ein .tib mit ca. 24 GB (was durchaus ok ist)

---------------

Danke für den Hinweis zu den Distfiles (ca.4 GB) und es gibt keine anderen User.

Ich bin mal offen und ehrlich. Eigentlich reise ich nur mit calc.

gentoo ist zwar installiert und ge-emerged und manchmal wirds gestartet, um zu sehen, 

obs noch läuft....benutzt wird es allerdings nicht *hust*

Wenn gparted meldet, da sind 35 GB (/dev/sdb6) belegt, dann wird das wohl so sein

----------

## LuxJux

Oft genug hab ich hier gelesen: ----------"Bevor eine Neuinstallion gemacht/notwendig wird, ....reparier doch einfach dein gentoo."

Gut. (Erstmal mein 13-Profil zurückgespielt)

```
emerge --sync
```

 *Quote:*   

> It is --highli recommended for doing a "emerge -1 portage"

 

Da gabs dann "ganz viele Fehler"

Was solls, dann nehm ich halt portage so wie es ist.

Nach 793 von 900 Paketen brach es ab. ( qtwebkit 5.9.1.5 )  --keep-going funktioniert nicht ) )

Vorsichtshalber nochmal "emerge -1 portage" (Ja, das geht jetzt)

Also nochmal Profile17 --empty-tree (Für Profil17-Update muß mit --emtpt-tree gemacht werden) 

Wieder 793/900 qtwebkit Abbruch. --keep-going funktioniert immer noch nicht

Habs erstmal "eingefroren"...19 GB

--------------------------

P.S.: Das 169GB-gentoo funktioniert einwandfrei

----------

## Tyrus

Einfach mal nachfrag - welches Verzeichnis ist denn da so vollgestopft? Hasse mal versucht das etwas einzugrenzen? 169GB Gentoo - und du bist sicher das das alles wirklich aus dem Portage-Tree kommt? 

Ich hab selber ja auch ein sehr umfangreiches Gentoo. Aber komme trotzdem nur auf 51GB fürs System - ohne /home und ohne /usr/local.

Edit:

Grade nochmal nachgesehen - von den 51 GB fallen aber schon 21 GB auf distfiles.  :Wink: 

----------

## firefly

Moment. Du erstellst mit True-Image ein backup?

In welcher form wurde das backup erstellt?

Wenn das backup auch die informationen über die partitionierung der Festplatte enthält dann gibt es folgenden Grund wiso das backup so groß ist.

AFAIK wird in diesem Falle einfach eine 1zu1 kopie aller parititionen erstellt. Wenn jetzt die Daten auf einer Paritition sehr verteilt sind (z.b. ein teil am anfang der patition, ein teil in der mitte und ein teil am ende) dann sind nicht sehr viele freiräume da die man effizient komprimieren könnte.

Dadurch steigt der benötigte Speicherbedarf immens.

z.b. eine Parition ist 50GB groß aber nur zu 50% gefüllt (25GB) Wenn die daten jetzt ungünstig vom Dateisystem auf der Partition verteilt sind, gibt es nicht genügend große zusammenhängende unbenutze blocke, die effizient (komprimiert) im backup image gespeichert werden können.

Dadurch kann es im schlimmsten falle sein, dass das backup image im oben genannten Beispiel 90% - 99% der größe der Paritition benötigt (z.b. 45-49GB) obwohl nur 25GB an nutzdaten vorhanden sind.

----------

## Josef.95

 *LuxJux wrote:*   

> Wieder 793/900 qtwebkit Abbruch.

  Falls du Interesse an einer Lösung hast, dann mache dafür am besten einen neuen Thread auf, mitsamt Fehlermeldung (build.log) und der dazugehörigen `emerge --info` Ausgabe.

Ich bin mir relativ sicher, dass da geholfen werden könnte :)

----------

## LuxJux

Die Suche hat zwar etwas gedauert, doch /dev/sdb6/proc/kcore belegt 128 GB (Calculate/Dolphin). 

( Edit: 140,7 TB (140.737.477.881.856 Bytes) gentoo/Dolphin )

Was ja eigentlich nicht sein sollte.

[url=https://www.linuxquestions.org/questions/linux-general-1/proc-kcore-%3D|-354466/] Hier [/url] und  Hier  hab ich was dazu gefunden (verstehe es jedoch nicht).

Edit: OT

Wie kann man denn einen Screenshot/Datei anhängen hier einfügen ?

----------

## firefly

 *LuxJux wrote:*   

> Die Suche hat zwar etwas gedauert, doch /dev/sdb6/proc/kcore belegt 128 GB (Calculate/Dolphin). 
> 
> ( Edit: 140,7 TB (140.737.477.881.856 Bytes) gentoo/Dolphin )
> 
> Was ja eigentlich nicht sein sollte.
> ...

 

öhm /proc braucht man auch nicht zu sichern, nach /proc wird ein virtuelles dateisystem gemountet, welches daten vom kernel enthält.

Kann es sein, dass du ein backup von gerade laufenden system aus gemacht hast?

Das ist gar nicht gut.

Neben /proc sind auch /sys und /dev keine Kandidaten welche gesichert werden müssen. /sys ist wir /proc es ist nur ein mount point für ein virutelles dateisystem vom kernel selbst.

----------

## LuxJux

 *firefly wrote:*   

> Wenn jetzt die Daten auf einer Paritition sehr verteilt sind (z.b. ein teil am anfang der patition, ein teil in der mitte und ein teil am ende) dann sind nicht sehr viele freiräume da die man effizient komprimieren könnte.
> 
> Dadurch steigt der benötigte Speicherbedarf immens.

 

Danke, firefly.  :Very Happy:  Das wars. Nach einem defrag beträgt die Größe des Archivs nun 15,9 GB.

----------

## LuxJux

Das Problem ist ja nun gelöst.

Das script hab ich 3x mal durchlaufen lassen.

Bei google find ich immer nur: Bei linux benötigt man kein defrag

 *Quote:*   

> plasma ~ # fsck -f -v /dev/sdb6
> 
> fsck von util-linux 2.31.1
> 
> e2fsck 1.43.6 (29-Aug-2017)
> ...

 

Können die 3,7% nicht doch irgendwie zusammengehängt werden ?

----------

## firefly

 *LuxJux wrote:*   

>  *firefly wrote:*   Wenn jetzt die Daten auf einer Paritition sehr verteilt sind (z.b. ein teil am anfang der patition, ein teil in der mitte und ein teil am ende) dann sind nicht sehr viele freiräume da die man effizient komprimieren könnte.
> 
> Dadurch steigt der benötigte Speicherbedarf immens. 
> 
> Danke, firefly.  Das wars. Nach einem defrag beträgt die Größe des Archivs nun 15,9 GB.

 

Naja man muss auch kein Backup auf partitionsebene machen  :Wink:  Dann ist die position der Daten/Dateien auf der Partition egal.

Es reicht wenn man die Daten an sich als backup kopiert und falls unbedingt notwendig die Information wie die Zielplatte partitioniert und mit welchen Dateisystem die einzelnen partitionen formatiert werden sollen.

Und die aussage stimmt schon, dass man unter linux normalerweise kein defrag braucht. Da die "linux" dateisysteme (treiber) versuchen neu zu speichernde Daten on block zu schreiben und nicht verteilt.

Ein Defrag run, welche alle Daten zu einem block zusammen kopiert (wobei die einzelnen Dateien dabei unter umständen immer noch fragmentiert sind) ist nur notwendig, wenn man auf partitionsebene ein Backup macht und dabei den unbelegten Platz so effizient wie möglich im backup image zu speichern.

So ein Backup auf Partitionsebene hat folgende Nachteile:

- Die Ziel Disk muss mindestens so groß sein wie die Disk von dem das Backup erstellt wurde, auch wenn nur ein bruchteil der partitionsgröße mit Daten gefüllt ist.

- Beim simplen zurückspielen des Backups auf eine größere Disk ist der zusätzliche Speicherplatz erstmal unbenutzbar. Es müssen weitere Schritte nach dem zurückspielen durchgeführt werden um eine oder mehrere Partition zu vergrößern um den zusätzlichen verfügbaren Speicherplatz nutzen zu können.

----------

## mv

Wenn "defrag" die Kompression einer gesamten Partition wirklich verbessert haben sollte, ist das Zufall.

Ein zuverlässiger Weg für die gute Kompression einer Partition zu sorgen besteht darin, den unbenutzten Speicher mit (z.B.) Nullen zu füllen: 

```
dd if=/dev/zero of=$EINE_NEUE_DATEI_DER_PARTITION
```

(Nach dem Syncen die Datei natürlich wieder entfernen.)

Aber Vorsicht: Bei viel freiem Plattenplatz braucht das Kommando sehr lang (außerdem sollte es am besten als root von einem anderen System aus aufgeführt werden).

(Und bei verschlüsselten oder komprimierenden Dateisystemen erfüllt das Füllen mit Nullen natürlich nicht den gewünschten Zweck.)

Aber wie firefly schon schrieb: Ein Backup auf Partitionsebene ist normalerweise die schlechteste Wahl. Das sollte man nur machen, wenn es einen anderen zwingenden Grund dafür gibt (etwa, dass man Backup oder Rückspielung unbedingt ohne Filesystem-Treiber durchführen muss).

----------

## LuxJux

Gut, dann war das Glück. Der Vorschlag war richtig und es hat funktioniert.

Könnte auch daran gelegen haben, daß zwei große Ordner (ca.100GB) nach dem Profil17-Update gelöscht wurden.

Und bitte entschuldigt. 

Ich bin ja schon glücklich Win8, gentoo und calc gleichzeitig geschauckelt zu bekommen. So als Umsteiger.

Gäbe es Hon Lik nicht, wäre ich wahrscheinlich nie bei gentoo gelandet.

----------

