nach format bleiben von 80GB nur noch 72 übrig :-(?

[meinereinerseiner]

hi,

mal eine Frage, hab in meiner Linux Kiste 3 80er Platten:


Festplatte /dev/hde: 255 Köpfe, 63 Sektoren, 10011 Zylinder
Einheiten: Zylinder mit 16065 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hde1 * 1 10011 80413326 83 Linux


Festplatte /dev/hdg: 16 Köpfe, 63 Sektoren, 159560 Zylinder
Einheiten: Zylinder mit 1008 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hdg1 * 1 159560 80418208+ 83 Linux



Festplatte /dev/hdk: 255 Köpfe, 63 Sektoren, 9729 Zylinder
Einheiten: Zylinder mit 16065 * 512 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hdk1 * 1 9729 78148161 83 Linux


/dev/hde1 75G 22G 49G 31% /mnt/daten_dev/hde1
/dev/hdg1 75G 72G 10M 100% /mnt/daten_dev/hdg1
/dev/hdk1 73G 33M 69G 1% /mnt/daten_dev/hdk1

alle platten sind mit einem ext3 formatiert.
mal abgesehen davon, das selbst nach dem Partion anlegen aus 80GB nur 75 bzw 73
übrig bleiben, verbraucht das ext3 ja nochmal 4 GB (siehe hdk1 - da sind noch keine Daten
drauf!) - bloss für was, das Journal kanns nicht sein - so groß ist das niemals nicht, oder
ist es die Blocksize?

Unter W2K(ntfs) passte jedenfalls wesentlich mehr auf die Platten!?

Was sind sinvolle Parameter fürs mkfs.ext3 bei so großen Platten - performance ist nicht
so die Bedingung.


DANKE

der tom

[schnebeck]

Vieleicht nur ein GigaByte vs Gibibyte-Problem?

80 *1000 *1000 / 1024 / 1024 = 76

Hier meine "Platten" - ok,ok diskless system ;-)

"Normal" (1024)
df -h

Filesystem Size Used Avail Use% Mounted on
192.168.1.1:/tftpboot/192.168.1.3 24G 21G 3.1G 87% /
tmpfs 1.0M 136K 888K 14% /mnt/.init.d
192.168.1.1:/video 39G 28G 12G 72% /video
192.168.1.1:/media 15G 14G 994M 94% /media
192.168.1.1:/media/video 57G 56G 847M 99% /media/video

"SI" (1000)
df -hH

Filesystem Size Used Avail Use% Mounted on
192.168.1.1:/tftpboot/192.168.1.3 25GB 22GB 3.4GB 87% /
tmpfs 1.1MB 140kB 910kB 14% /mnt/.init.d
192.168.1.1:/video 42GB 30GB 12GB 72% /video
192.168.1.1:/media 16GB 15GB 1.1GB 94% /media
192.168.1.1:/media/video 61GB 60GB 888MB 99% /media/video

und so wird ein 61GB-Platte als eine 57GB-Platte je nach System gelistet.

Abgesehen davon (hab' jetzt keine Lust darüber nachzudenken, ob deine Rechnung mit Blöcken und Sektoren gegen meinen Hinweis spricht ;-) ist erstmal bei großen Platten der Verlust pro Datei ebenfalls groß, da selbst eine z.B 2-Byte große Datei natürlich gleich einen ganzen Block verbrät. Insgesamt erscheint mir das Ergebnis 80GB-Platte -> 75GB freien Speicherplatz plausibel zu sein!?

Da Linux ja ntfs von win2k lesen kann, wäre es interessant nochmal eine Platte unter Win zu formatieren, unter Linux zu mounten und mit du -h sich die Größe anzuschauen.

Bye

Thorsten

[meinereinerseiner]

hab mal reiserFS genommen und siehe da:

/dev/hdk1 74G 33M 74G 1% /mnt/daten_dev/hdk1

das nimmt sich nur 33MB!

was ist bei ext3 anders?

[pitfl]

Hi,
die formatierte Kapazität ist immer geringer, als auf den Festplatten angegeben.
Schau Dir mal ein paar Datenblätter von Festplatten an, z. Beispiel bei www.alternate.de.
Dort steht bei den 80GB Festplatten, als formatierte Kapazität ungefähr der Wert, den Du auch festgestellt hast.
Diese Reduzierung ist eigentlich unabhängig vom verwendeten Dateisystem.
mfg
pit

[meinereinerseiner]

naja - also was die angabe auf platte und der tatsächlichen angeht, das verstehe ich schon,
das war ja schon seit eh und je so - allerdings gings mir darum, das wenn ich die platte
mit einem ext3 formatiere von den ehemals 73G nur 69G verbleiben, was heist es gehen mir
4GB irgendwie verloren, formatiere ich hingegen mit reiserFS bleiben mir die 73G voll erhalten.


der tom

[f0rtex]

Ich weiss nicht wie es bei Journaling FS aussieht, aber bei ext2 war es so, dass default-mässig immer 5% für den user root übrig gelassen wurden.
Da konnte man mit tune2fs -m 0 <device> die Anzahl reservierter Blöcke auf 0% stellen.
evtl. gibt es ja en tune3fs oder so ;-)

MfG
f0rtex

[cirad]

Es ist spät (früh) und ich bitte, Rechtschreib- und Rechenfehler zu entschuldigen.

Das hat 2 mir bekannte Gründe:

1) Der Fall wurde gerade schon genannt. 5% sind standardmäßig für root reserviert. Das ist bei ext2 genauso wie bei ext3.
Das eigentliche Journaling-File ist bei ext3 glaube ich 32MB groß, ebenso bei ReiserFS.


2) Eine Inode (Erklärung kommt noch) ist 128Byte groß ... das klingt erstmal nicht viel. Aber rechnen wir ein bischen mit Standardwerten von ext3:

Ein Block in ext3 ist standardmäßig 4096 Byte = 4KB groß, das macht

80GB = 80*2^20 KB = 83.886.080 KB
83.886.080 KB / 4 KB = 20.971.520 Blöcke

Auf eine Inode kommen bei ext3 standardmäßig 2 Blöcke, du hast demnach 10.485.760 Inodes. Jede Inode ansich verbraucht wie gesagt 128 Byte.

10.485.760 * 128 Byte = 1280MB

Die gehen also durch die große Inode-Anzahl 1.25GB (!) flöten. Was sind Inodes? Jede Datei braucht ein Inode, um Dateirechte und ähnliches zu speichern. Bei ext3 sind Inodes aber statisch, also fest im Filesystem. Du kannst einmal die Anzahl der Inodes festlegen, danach läßt sie sich nicht mehr ändern (außer neu mit "formatieren"). ReiserFS hingegen verwaltet Inodes dynamisch.

ext3 nimmt standardmäßig an, daß eine Datei durchschnittlich 8KB groß ist und legt daher für alle 8KB eine Inode an. Das ist in deinem Fall vermutlich Irrsin, da du keine 10.485.760 Dateien/Verzeichnisse (= Inodes) anlegen wirst. Es ist aber möglich, mke2fs selbst eine Zahl mit auf den Weg zu geben, wieviele Inodes auf wieviel Byte kommen sollten.

mke2fs -i 524288 /dev/hde1
nimmt Dateigrößen von 512KB an und legt dementsprechend viele Inodes an (Plattengröße / 512KB = Inodes).

mke2fs hat noch eine andere Option:
mke2fs -T largefile /dev/hde1
Dabei wird für largefile 1MB = 1024KB angenommen. Für -T news = 4KB und für -T largefile4 = 4 MB.

Angenommen du "Formatierst" du deine Partition mit der Option -T largefile:
83.886.080 KB / 1024KB = 81920 Inodes
81920 * 128 Byte = 10MB

10MB Verlust sind denke ich Verschmerzbar, gegenüber den 1280MB von davor. Über 80.000 Dateien sollten vollkommen ausreichen, denn 80GB füllt man ohnehin meist mit Filmen und MP3s, die alle größer als 1 MB sind (-T largefile = 1MB pro File im Durchschnitt) angenommen.

Sollte dir das zuwenig oder zuviel vorkommen, kannst du ja mit -T largefile4 oder -i die Werte ändern (2MB pro File im Schnitt annehmen, oder 0.5MB). Aber VORSICHT!!! Wie gesagt läßt sich das nicht mehr nachträglich ändern. Solltest du nur 8000 Inodes eingestellt haben und willst die 8001ste Datei schreiben, dann wird er dir mit einer Fehlermeldung kommen. Es macht aber eigentlich keinen Sinn, die 80.000 noch weiter runterzuschrauben ... 10MB von 80.000MB sind wirklich nicht die Welt.

So, ich hoffe das war ausführlich genug und ist nicht komplett unverständlich (auch der Uhrzeit wegen). Und ich hoffe, daß liest sich überhaupt noch jemand durch.

PS: Ich würde dir von ReiserFS trotz alle Geschwindigkeitsvorteile abraten. Ich habe seit dem ersten 2.4er Kernel bis heute ReiserFS genutzt und mehrfach Probleme gehabt. (Editieren von einer Datei XYZZY und gleichzeitig surfen -> Reset gedrückt (Absturtz) -> führte dazu, daß HTML-Seiten aus dem Konqueror-Cache in meiner Datei XYZZY auftauchtet. Das Problem bestand auch beim 2.4.18er weiterhin, danach hat mich das nicht mehr interessiert. Ich kann nicht behauptet, daß mir sowas mit ext3 passiert wäre.

[cirad]

> evtl. gibt es ja en tune3fs oder so ;-)

Nein, das läuft ebenfalls über tune2fs. ext3 ist quasi ext2 + Journaling File. Alle ext2-Tools lassen sich auf ext3 anwenden. Das ist ein Vorteil von ext3, da es für ext2 ausgereifte Tools gibt.

So kannst du unter Windows mit Tools ext3-Partitionen als ext2 lesen. Oder du kannst in FreeBSD ext3-Partitionen als ext2 mounten.

[meinereinerseiner]

danke für die antworten - hat reichlich licht ins dunkel gebracht!!


der tom