Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[gelöst] 35 GB gentoo-archive benötigt 161.5 GB
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Sat May 05, 2018 9:42 pm    Post subject: [gelöst] 35 GB gentoo-archive benötigt 161.5 GB Reply with quote

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
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2123
Location: Germany

PostPosted: Sun May 06, 2018 4:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Sun May 06, 2018 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Tue May 08, 2018 9:38 pm    Post subject: Reply with quote

Oft genug hab ich hier gelesen: ----------"Bevor eine Neuinstallion gemacht/notwendig wird, ....reparier doch einfach dein gentoo."
Gut. (Erstmal mein 13-Profil zurückgespielt)
Code:
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
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 99

PostPosted: Tue May 08, 2018 9:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4362

PostPosted: Wed May 09, 2018 6:37 am    Post subject: Reply with quote

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
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 3419
Location: Germany

PostPosted: Wed May 09, 2018 3:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Thu May 10, 2018 2:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4362

PostPosted: Thu May 10, 2018 5:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Fri May 11, 2018 6:21 pm    Post subject: Reply with quote

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. :D Das wars. Nach einem defrag beträgt die Größe des Archivs nun 15,9 GB.
Back to top
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Fri May 11, 2018 10:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4362

PostPosted: Fri May 11, 2018 10:57 pm    Post subject: Reply with quote

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. :D 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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6107

PostPosted: Sun May 13, 2018 5:46 am    Post subject: Reply with quote

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
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 269

PostPosted: Sun May 13, 2018 7:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum