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)
Ext4 reserviert Platz für sein eigenes Journal. Die Größe kannst du einstellen.
● 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.
● J-A V. schrieb: > 8,1 GIGA-byte? Ja. https://rwmj.wordpress.com/2009/11/08/filesystem-metadata-overhead/ Auszug daraus:
1 | Filesystem
|
2 | |
3 | Allocated kilobytes (out of 1G) |
4 | |
5 | Overhead % |
6 | |
7 | ext2 16948 1.6% |
8 | ext3 [2] 33352 3.2% |
9 | ext4 [2] 33288 3.2% |
10 | xfs 5132 0.5% |
11 | ntfs [3] 5748 0.5% |
12 | msdos & vfat 2076 0.2% |
13 | reiserfs [3] 32916 3.1% |
14 | btrfs [3] 4224 0.4% |
15 | hfs & hfsplus [3] 16432 1.6% |
16 | nilfs2 [3] 2060 0.2% |
17 | jfs [3] 4364 0.4% |
18 | gfs [3] 16612 1.6% |
19 | gfs2 [3,4] 132576 12% |
Die Platte ist eine 160GB SATA
Kommt nicht wirklich hin. 180 * 3,2 / 100 = 5,78 Mal mit einem Tool wie dumpe2fs schauen, wofür die reservierten Blöcke benutzt werden.
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...
Noch einer schrieb: > Kommt nicht wirklich hin. 180 * 3,2 / 100 = 5,78 Und die Größenordnung passt doch.
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.
ext erstellt einen für root reservierten Bereich auf der Platte - vielleicht ist es das, was du als belegten Platz siehst? siehe http://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why Default sind 5%, was ja den 8 GB entspricht.
1 | #!/bin/bash
|
2 | |
3 | Filesystems="ext2 ext3 ext4 ext4dev minix ntfs xfs btrfs fat msdos vfat" |
4 | |
5 | for size in 100M 1G 10G 100G; do |
6 | echo "Size: $size" |
7 | for fs in $Filesystems; do |
8 | if [ $fs == ntfs ]; then |
9 | Options="--force --quick" |
10 | else
|
11 | Options="" |
12 | fi
|
13 | File="Test.${fs}" |
14 | truncate -s $size "${File}" |
15 | /sbin/mkfs.${fs} $Options "${File}" >/dev/null 2>&1 |
16 | du -h "${File}" |
17 | rm "${File}" |
18 | done
|
19 | echo |
20 | done
|
Resultate:
1 | Size: 100M |
2 | 3,6M Test.ext2 |
3 | 7,6M Test.ext3 |
4 | 4,4M Test.ext4 |
5 | 4,4M Test.ext4dev |
6 | 700K Test.minix |
7 | 2,5M Test.ntfs |
8 | 3,7M Test.xfs |
9 | 4,1M Test.btrfs |
10 | 220K Test.fat |
11 | 220K Test.msdos |
12 | 220K Test.vfat |
13 | |
14 | Size: 1G |
15 | 17M Test.ext2 |
16 | 49M Test.ext3 |
17 | 33M Test.ext4 |
18 | 33M Test.ext4dev |
19 | 700K Test.minix |
20 | 5,6M Test.ntfs |
21 | 11M Test.xfs |
22 | 4,4M Test.btrfs |
23 | 2,1M Test.fat |
24 | 2,1M Test.msdos |
25 | 2,1M Test.vfat |
26 | |
27 | Size: 10G |
28 | 164M Test.ext2 |
29 | 292M Test.ext3 |
30 | 131M Test.ext4 |
31 | 131M Test.ext4dev |
32 | 700K Test.minix |
33 | 52M Test.ntfs |
34 | 11M Test.xfs |
35 | 4,4M Test.btrfs |
36 | 11M Test.fat |
37 | 11M Test.msdos |
38 | 11M Test.vfat |
39 | |
40 | Size: 100G |
41 | 1,6G Test.ext2 |
42 | 1,7G Test.ext3 |
43 | 133M Test.ext4 |
44 | 133M Test.ext4dev |
45 | 700K Test.minix |
46 | 68M Test.ntfs |
47 | 51M Test.xfs |
48 | 4,4M Test.btrfs |
49 | 26M Test.fat |
50 | 26M Test.msdos |
51 | 26M Test.vfat |
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.
@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"%" }'
Ne, vergiss es. dumpe2fs kennt extFs aber die anderen nicht.
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.
:
Bearbeitet durch Moderator
selbstverständlich war mir klar, dass ein DateiSystem Platz benötigt. mir war nur nicht klar, dass es da soviel ist. danke für die Infos :)
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.
nein es sind 2GB, 2x 1GB
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.