Speilerei mit 'ner HDD unter Ubuntu/Gparted

Masl schrieb:
> Ein Dateisystem belegt immer Platz.

8,1 GIGA-byte?

Die Platte ist eine 160GB SATA

● 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.

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 schrieb:
> Alles ist im Fluss...

Das gilt nur für die Bewohner der Randplaneten

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:
> 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.

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.

Okay, dann habe ich wieder was gelernt. :-)

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.

nein es sind 2GB, 2x 1GB