Ich wollte eine Festplatte löschen,
die vorher von mir Daten drauf hatte.
Dazu habe ich erstmal alles "normal gelöscht":
In den Papierkorb, diesen geleert mit "dd" den gesamten Bereich
der Platte einmal überschrieben.
Das war noch als die Platte ein NTFS-System drauf hatte.
nun wollte ich mit GParted eine neue ext4-Partition
(eine Partition auf der gesamten Platte)
einrichten und sehe, dass direkt nach dem Fertigstellen
bereits ein kleiner gelber Balken prangt.
Es werden satte 8,1GB belegter Platz angezeigt.
danach habe ich mit anderen Dateisystemen "herumgespielt".
wenn ich ein NTFS erzeuge oder ein FAT32,
wird kein Platz belegt.
Danach wieder ein ext4 angelegt
und wieder ist ein 8,1GB Bereich belegt.
Bei einem ext2 sind es 2,4Gig.
Ist das richtig so? ist das irgendwas für ein System reserviertes Zeug?
Das ganze soll ein neu aufgebauter Rechner werden,
mit Gebraucht-Teilen (nicht allzu alt)
● J-A V. schrieb:> wenn ich ein NTFS erzeuge oder ein FAT32,> wird kein Platz belegt.> Danach wieder ein ext4 angelegt> und wieder ist ein 8,1GB Bereich belegt.> Bei einem ext2 sind es 2,4Gig.
Ein Dateisystem belegt immer Platz.
Ist ja klar, irgendwo muss die Info bzgl. Ordnerstruktur/physikalische
Position der Dateien/etc. ja untergebracht werden.
Im Übrigen könntest du viele deiner Probleme mit googlen lösen.
Wie Gross ist eigentlich die Platte? 8,1GB für Verwaltungsinformationen
ist bei einer 500GB Partition normal.
Googeln? Dafür muss man erst mal auf Begriffe wie Inode oder Journal
kommen.
Noch einer schrieb:> Kommt nicht wirklich hin. 180 * 3,2 / 100 = 5,78
Meingott, nimms halt genau...
Das sind Richtwerte, ermittelt mit einem Shellskript durch Ausprobieren.
Wahrscheinlich gibt es einen fixen Teil der unabhängig von der Größe des
Datenträgers ist sowie einen dynamischen.
Evtl. ändert dieser dynamische Teil auch seine Größe während des
Betriebes.
Aufs Byte genau wirst du das nur schwer ausmessen können...
Ich finde ja auch. Auf die paar Prozent kommt es nicht an.
Mit einem 1€ Job das Geld für eine grössere Platte verdienen geht
schneller als herausfinden, ob man da noch was optimieren kann.
Aber manchmal will man halt einfach wissen, wo das fehlende Bit ab
geblieben ist.
● J-A V. schrieb:> wenn ich ein NTFS erzeuge oder ein FAT32,> wird kein Platz belegt.
Das kann zwar sein, dass Deine Systemprogramme das so anzeigen, ist aber
nicht richtig.
Ein jungfräuliches FAT32-Dateisystem enthält immer zwei "file allocation
tables". Die brauchen Platz. Es kann sein, dass der nicht mitgezählt
wird.
Das Wurzelverzeichnis hat auch eine vordefinierte Mindestgröße. Dafür
geht auch Platz verloren.
Wenn Du ein NTFS-Dateisystem erzeugst, legt der Dateisystemtreiber auch
die MFT "master file table" an. In dieser sind alle Metadaten der
Dateien, bei kleinen Dateien auch ihre Inhalte enthalten. Dieser Platz
wird eventuell auch nicht mitgezählt.
Die MFT kann nicht nur vergrößert werden, sondern auch dynamisch
verkleinert.
Wenn Du also eine frische Partition mit einer Datei vollschreibst, wird
die ehemals große MFT kleingeschrumpft, damit freier Platz für Deine
Datei vorhanden ist.
Julius J. schrieb:> ext erstellt einen für root reservierten Bereich auf der Platte
Das wird es wohl sein.
Nur mal zur Differenzierung:
n1 - Anzahl der Blöcke (512B,4KiB) der Disk
n2 - Anzahl der Blöcke (512B,4KiB) des Volume (bspw. Partition)
n3 - Anzahl der Blöcke im Dateisystem (FS) des Volumes
n4 - Anzahl der freien Blöcke des FS
n5 - Anzahl der verfügbaren Blöcke im FS (also frei - reserviert)
Der TS bezieht sich wohl auf das Verhältnis von n3 zu n5.
egal schrieb:> @Norbert, bau das mal ein:>> dumpe2fs -h /dev/sdXY 2> /dev/null | awk -F ':' '{ if($1 == "Reserved> block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } }> END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'
Bei ext2/3/4 kann man auch das Dateisystem mit -m0 erstellen.
Dann hat man keine reservierten Blöcke für root.
Mit dem von mir vorher gezeigten bash-script werden die bei der
Erstellung des Dateisystems beschriebenen Bereiche gemessen.
Die (mögliche) Reservierung für 'root' spielt da keine Rolle
Da zB in der NTFS MFT kleine Dateien komplett untergebracht werden sowie
bei ext Dateisystemen Informationen in den Inodes gespeichert werden
können, kann das ganze sowieso nur einen Überblick liefern.
Eine Bitmap orientierte Speicherung braucht auch andere Größen als zB
eine extend Basierte.
Alles ist im Fluss...
Norbert schrieb:> Alles ist im Fluss...
Man könnte ja mal vergleichen Angaben von (g)parted nach Ausführung von
mkfs und inode-count*inode-size, eg. tune2fs -l sollte das liefern.
Norbert schrieb:> Dann hat man keine reservierten Blöcke für root.
Ist allerdings 'ne saublöde Idee, es sei denn, man benutzt das
Dateisystem so, dass man nie etwas löscht (bspw. nur immer neue
Backups schreibt).
Der reservierte Platz ist ja nicht dafür da, weil der Sysadmin immer
noch mehr bräuchte :), sondern er dient in erster Linie dazu, eine
übermäßige Fragmentierung zu verhindern. Durch die Dateisystemreserve
bleibt für den Layouter immer etwas Spielraum, eine möglichst gut
passende Stelle für neue Dateien zu finden.
Bei SSDs mag das allerdings keine Geige mehr spielen, denn dort ist
die Zugriffszeit unabhängig davon, wie weit die Blöcke auseinander
liegen.
Jörg W. schrieb:> Norbert schrieb:>> Dann hat man keine reservierten Blöcke für root.>> Ist allerdings 'ne saublöde Idee, es sei denn, man benutzt das> Dateisystem so, dass man nie etwas löscht (bspw. nur immer neue> Backups schreibt).>> Der reservierte Platz ist ja nicht dafür da, weil der Sysadmin immer> noch mehr bräuchte :), sondern er dient in erster Linie dazu, eine> übermäßige Fragmentierung zu verhindern. Durch die Dateisystemreserve> bleibt für den Layouter immer etwas Spielraum, eine möglichst gut> passende Stelle für neue Dateien zu finden.>> Bei SSDs mag das allerdings keine Geige mehr spielen, denn dort ist> die Zugriffszeit unabhängig davon, wie weit die Blöcke auseinander> liegen.
Was bei '/', '/var', usw. eine blöde Idee sein mag, kann bei anderen
Partitionen durchaus sinnvoll sein. Genau wie eine manuelle Einstellung
bzgl Inode count, usw.
Ganz generell kann man sagen,
das Verallgemeinerungen immer fehl am Platze sind. ;-)
Jörg W. schrieb:> Der reservierte Platz ist ja nicht dafür da, weil der Sysadmin immer> noch mehr bräuchte :), sondern er dient in erster Linie dazu, eine> übermäßige Fragmentierung zu verhindern.
Dazu muss man den Platz aber auch nicht reservieren. Solange man die
Partition nicht fast komplett auffüllt, hält sich das mit der
Fragmentierung in Grenzen. Und wenn es ein Problem wird, dann sind die
5% auch nur ein Tropfen auf dem heißen Stein.
Die Reservierung auf der Root-Partition ist aber wichtig, damit bei
einem randvollen Dateisystem durch $whatever wenigstens root sich noch
auf der Konsole einloggen und Daten löschen kann. Da reicht bei modernen
Größen aber auch 1%, weniger kann man wohl nicht angeben. Die beim Login
anfallenden Logdateien müssen jedenfalls reinpassen.
Große Datenpartitionen im Heimbetrieb füllt man mit großen,
sequentiellen Dateien (Filme, Backups, ...), die fragmentieren nicht
nennenswert, selbst wenn man hin und wieder löscht und neu baut. Da
braucht es auch keine Reservierung.
S. R. schrieb:> Und wenn es ein Problem wird, dann sind die 5% auch nur ein Tropfen auf> dem heißen Stein.
Nein, selbst bei 3 % ist noch eine brauchbare Defragmentierung
machbar. Erst darunter geht das völlig den Bach runter.
> Die Reservierung auf der Root-Partition ist aber wichtig, damit bei> einem randvollen Dateisystem durch $whatever wenigstens root sich noch> auf der Konsole einloggen und Daten löschen kann.
Wenn es nur dafür gewesen wären, hätten selbst vor 30+ Jahren, als
das Feature eingeführt worden ist (beim Berkeley FFS, von dem ext2fs
es übernommen hat), bereits 0,5 % genügt, und diese nur auf wichtigen
Dateisystemen.
> Große Datenpartitionen im Heimbetrieb füllt man mit großen,> sequentiellen Dateien
Wenn man viele Partitionen hat.
Das mittlerweile übliche Setup ist ja eher, eine einzige große
Partition zu haben.
Andererseits hat man mittlerweile auch bessere Dateisysteme, die völlig
anders arbeiten.
Jörg W. schrieb:> Nein, selbst bei 3 % ist noch eine brauchbare Defragmentierung> machbar. Erst darunter geht das völlig den Bach runter.
Hmm, ich hatte da irgendwas um die 10-20% im Kopf, ab denen das zum
Problem wird. Aber vermutlich ist das auch abhängig vom Dateisystem.
Jörg W. schrieb:>> Große Datenpartitionen im Heimbetrieb füllt man mit großen,>> sequentiellen Dateien>> Wenn man viele Partitionen hat.
Ich dachte eher an externe Festplatten für die Videosammlung.
S. R. schrieb:> Hmm, ich hatte da irgendwas um die 10-20% im Kopf, ab denen das zum> Problem wird. Aber vermutlich ist das auch abhängig vom Dateisystem.
Ich kenne solche Untersuchungen vom UFS (Berkeley FFS), und würde für
extNfs aufgrund seiner Wurzeln kein grundlegend anderes Verhalten
erwarten.
● J-A V. schrieb:> selbstverständlich war mir klar, dass ein DateiSystem Platz benötigt.> mir war nur nicht klar, dass es da soviel ist.
Hast du zufällig 4 GB Arbeitsspeicher in dem Bastelrechner?
Hab das in frühen Linux-Zeiten mal so verstanden, dass
ext2: eine SWAP Partition in Größe des RAM anlegt
ext4: eine SWAP Partition in Größe von 2x RAM anlegt
Nur eine Vermutung, kein Anspruch auf Richtigkeit
Gruß, Wolle
Wolle R. schrieb:> Nur eine Vermutung, kein Anspruch auf Richtigkeit
Ist auch komplett falsch.
Die Swap-Partition ist eine Partition, die ext2-Partition ist eine
Partition, beide haben genau nichts miteinander zu tun.
Ich dachte, der TE meinte die gesamte Festplatte, also ext4+swap
● J-A V. schrieb:> Danach wieder ein ext4 angelegt> und wieder ist ein 8,1GB Bereich belegt.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten