| View previous topic :: View next topic |
| Author |
Message |
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
 Posted: Sat May 05, 2018 9:42 pm Post subject: [gelöst] 35 GB gentoo-archive benötigt 161.5 GB |
 |
|
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
| Code: | 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 nicht
Last edited by LuxJux on Fri May 11, 2018 6:25 pm; edited 2 times in total |
|
| Back to top |
|
 |
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Sun May 06, 2018 4:37 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Sun May 06, 2018 5:51 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Tue May 08, 2018 9:38 pm Post subject: |
|
|
Oft genug hab ich hier gelesen: ----------"Bevor eine Neuinstallion gemacht/notwendig wird, ....reparier doch einfach dein gentoo."
Gut. (Erstmal mein 13-Profil zurückgespielt)
| 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 |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Tue May 08, 2018 9:52 pm Post subject: |
|
|
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.  |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5173
|
| Posted: Wed May 09, 2018 6:37 am Post subject: |
|
|
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.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4544
Location: Germany
|
| Posted: Wed May 09, 2018 3:55 pm Post subject: |
|
|
| 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 :) |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Thu May 10, 2018 2:09 pm Post subject: |
|
|
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 ? |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5173
|
| Posted: Thu May 10, 2018 5:37 pm Post subject: |
|
|
| 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.
[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 ? |
ö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.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Fri May 11, 2018 6:21 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Fri May 11, 2018 10:43 pm Post subject: |
|
|
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)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
742848 Inodes sind in Benutzung (4.62% von 16064512)
27176 nicht zusammenhängende Dateien (3.7%)
505 nicht zusammenhängende Verzeichnisse (0.1%)
# von Inodes mit ind/dind/tind Blöcken: 26221/319/0
7274583 Blöcke werden benutzt (11.32% von 64255232)
0 defekte Blöcke
1 große Datei
640887 reguläre Dateien
84048 Verzeichnisse
174 zeichenorientierte Gerätedateien
97 Blockgerätedateien
5 Fifos
0 Verknüpfungen
17623 symbolische Verknüpfungen (17429 schnelle symbolische Verknüpfungen)
5 Sockets
------------
742839 Dateien
plasma ~ # |
Können die 3,7% nicht doch irgendwie zusammengehängt werden ? |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5173
|
| Posted: Fri May 11, 2018 10:57 pm Post subject: |
|
|
| 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 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.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun May 13, 2018 5:46 am Post subject: |
|
|
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: | Code: | | 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). |
|
| Back to top |
|
|
LuxJux
Guru
Joined: 01 Mar 2016
Posts: 497
Location: Germany/Berlin
|
| Posted: Sun May 13, 2018 7:40 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
Deutsches Forum (German)
