Kapazitäten Dieb wurde gefasst :D

[daemotron]

Da diese ungleiche Verwendung von Zehner- und Zweierpotenzen bei Hard- und Softwareherstellern auch schon vor der IEC-Normung (wer sagt schon "MiB" und "KiB"? ) Usus war, könnte man auch sagen, dass weiterhin von den Plattenherstellern besch*ssen wird - nur haben sie sich offenbar bei der Normung durchgesetzt, so dass jetzt auf einmal die OS-Bastler die "Bösen" sind :D

[oxygen]

Auf der Letzten Platte die ich gekauft hab, stand 120 GB (128 GiB). Das war eigentlich fair.

[oxygen]

In deinem Fall geht durch die Formatierung mit ext3 einiges verloren. vgl dazu -E resize=XXXG

[hornox]

Auf der Letzten Platte die ich gekauft hab, stand 120 GB (128 GiB). Das war eigentlich fair.

Offensichtlich aber verwirrent. 128 GB entspricht 120 GiB, andersrum ist es falsch :D

Wer jetzt an der inkonsquenten Umsetzung schuld ist, kläre meinetwegen das jüngste Gericht.

Die Maßeinheiten bei df sind in den man Pages dokumentiert und mit Parameter -H umschaltbar. IMHO könnte ist es deswegen mindestens zum Teil ein Bedienungsfehler.
Erst wenn jemand auf die Idee kommt bei Arbeitsspeicher und SSDs die GB SI konform anzugeben werde ich genervt...

[oxygen]

Auf der Letzten Platte die ich gekauft hab, stand 120 GB (128 GiB). Das war eigentlich fair.

Offensichtlich aber verwirrent. 128 GB entspricht 120 GiB, andersrum ist es falsch :D

Mein Fehler. Auf der Packung stehts richtig.

[oxygen]

Mir ging es eigentlich mehr darum, dass cfdisk und df unterscheiden. Also die entwickler wohl um die Unterschiede wissen, aber es einfach nicht konsequent mit einem standrd umgesetzt haben.

Das liegt wie gesagt an der Formatierung mit ext3, die einigen Overhead erzeugt. Mit anderen Dateisystemen (bzw auch mit anderen Formatierungensoptionen, s.o.) ist das weniger gravieren.

[nyxus]

Nein nicht wirklich.

Der Overhead macht keine knapp 20 Gb aus.
Nicht mal bruchteilhaft.

Meinst Du evt. die standardmäßigen 5%, die für den root reserviert sind, Oxygen? Mit ein bißchen gutem Willen kann man das ja auch als Overhead durchgehen lassen. ;-)

[oxygen]

Nein, ich meine nicht die reserved blocks for superuser.

Sondern den Overhead den das Dateisystem erzeugt. Schauen wir uns folgendes an:

Code: Select all

dd if=/dev/zero of=file bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 31.0272 s, 33.8 MB/s

# mkfs.ext3 file
mke2fs 1.41.3 (12-Oct-2008)
file is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
64000 inodes, 256000 blocks
12800 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=264241152
8 block groups
32768 blocks per group, 32768 fragments per group
8000 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 27 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


# mount -o loop file /mnt/tmp

# df /mnt/tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop0             1007896     17668    939028   2% /mnt/tmp

Wenn man die Anzahl bytes betrachtet (Device Size vs. Partition Size), hat man hier bereits einen Verlust von 4%. Dieser wächst in n*log(n) mit n = Größe des Device. Bei einer 1TB Festplatte sind es bereits 20%. Vergleichen wir hier z.B. mal reiserfs3.6, welches auch nicht gerad das beste Dateisystem ist:

Code: Select all

df /mnt/tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop0             1023964     32840    991124   4% /mnt/tmp

Hier beträgt der "blockschwund" nur weniger als 2%.

[daemotron]

Inode-Tabellen, das Journal, ...

[oxygen]

Durch was ist der Speicher dann belegt?
Die Partitionestabellen werden ja nich so gross.

Die Partitionstabelle (nur eine + Backup) ist tatsächlich nicht groß. Der Overhead von Dateisystemen entsteht hauptsächlich durch die Indexstrukturen und Metadaten, das Journal ist auch ein Faktor, aber einer konstanter. Sowohl Indexstrukturen als auch Metadaten werden immer komplexer um eine höhere Performance und zusätzliche Features zu realisieren. Insbesondere die Indexstrukturen werden aber immer mehr zu einem Problem, da diese stärker als linear anwachsen.
Für weitere Infos würde ich Dokumentationen zu ext3 empfehlen. Es gehört zu den am besten dokumentierten Teilen des Linux Kernels. Eine kompakte Anlaufstelle ist z.B: http://www.heise.de/open/Das-Dateisyste ... kel/104859

[oxygen]

Und ganz blöde gefragt, was macht an der Stelle xfs besser z.B. ?

Besser? Anders ist wohl hier das richtige Wort. Alles hat Vor und Nachteile. Im Hinblick auf den Overhead gilt aber, einfacher ist besser. Interessanterweise liegt hier nach meinem Stand exFAT am besten im Rennen, da es auf komplexe Indexstrukturen verzichtet sondern eine aufgebohrte FAT benutzt.

Wenn man die aktuellen Dateisysteme betrachtet gibt es zwar Unterschiede in den verwendeten Indexstrukturen, diese sind aber nicht sehr gravierend. Während ext3 auf den H-Baum setzt, nutzten XFS und Rieser3 den B+ Baum. Reiser4 B*-Baum.
Ein paar Gigabyte (bei aktuellen Festplattengrößen) kann man aber leicht mit angepassten Formatierungsoptionen rauskitzeln. Insbesondere bei ext3.

Einen nennenswerten Unterschied bringt hier erst ZFS, welches keine Baumstruktur sondern eine Hashtable nutzt.

[oxygen]

Ja, in vielen Fällen lohnt der Aufwand nicht.

Mir ging es auch primär darum aufzuzeigen, dass es sich hier weder um Betrug oÄ noch um eine Inkonsequenz handelt.
Es ist einfach eine technische Beschränkung.

[oxygen]

Der Verlust der Kapazität geht halt auf zwei Komponenten zurück.

Die erste Komponente, die Umrechnung GB <-> GiB dürfte jedem klar sein. Ist im Grunde ja ein alter Hut.

Die zweite Komponente dagegen hat nichts mit Standards oÄ zu tun, sondern ist wie oben erklärt eine technische Einschränkung.
Die unterschiedlichen Anzeigen von fdisk -l und df sind konsequent. fdisk betrachtet nur die rohen bytes der Partition da es nichts über das Dateisystem weiß. df dagegen zeigt die für den Benutzer sichtbaren bytes nach erstellen und mouten des Dateisystems.

[oxygen]

,
Der Unterschied zwischen der Angabe auf fdisk und df beruht auf dem Unterschied GIB zu GB + Partitionstabelle.

Nein. Die Partitionstabelle existiert wie bereits erwähnt nur einmal bzw. zweimal im Bootsektor.

Ich habe doch oben demonstiert, dass die Anzahl der echten bytes des Devices nicht der Anzahl Bytes entspricht die df ausgibt. df gibt nur die nutzbaren bytes aus (nach abzug des Overheads durch das Dateisystem), fdisk die physikalischen.

Also nochmal mit Erklärung:

Code: Select all

# dd if=/dev/zero of=file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 26.0325 s, 41.2 MB/s

wir erstellen also ein Block Devices, dass genau 1073741824 (1024^3) Bytes hat.

Code: Select all

# mkfs.ext3 file
mke2fs 1.41.3 (12-Oct-2008)
file is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# mount -o loop file /mnt/tmp

weiterhin formatieren wir diese Devices mit ext3 und mounten es.

Code: Select all

# df /mnt/tmp -B1
Filesystem           1B-blocks      Used Available Use% Mounted on
/dev/loop0           1056858112  34906112 968265728   4% /mnt/tmp

Hier geben wir uns die genaue Anzahl Bytes des Dateisystems aus: 1056858112 Bytes.

1056858112 bytes < 1073741824 bytes (+ 1,59 %) (Dateisystemgröße 1 GB)

Da hier keine Umrechnung G/M/K stattgefunden hat, gibt es auch keine Fehler. Eine Partitionstabelle sowieso nicht, da es sich ja um keine Partition handelt.

zum Vergleich nochmal reiserfs3.6

Code: Select all

# df /mnt/tmp -B1
Filesystem           1B-blocks      Used Available Use% Mounted on
/dev/loop0           1073704960  33628160 1040076800   4% /mnt/tmp

1073704960 bytes < 1073741824 bytes (~ +/- 0 %) (Dateisystemgröße 1 GB)

[oxygen]

modprobe loop könnte helfen.

[oxygen]

Wenn ich nun nicht ganz durcheinander bin, dann nimmt doch der Overhead einer ext3 Partition mit der grösse der Partiton stärker und nicht linear zu.

Das war ja meine Eingangsbehauptung, weil ich es so in Errinnerung hatte. Ich habe jetzt nochmal ein wenig rumprobiert. Das ist grundsätzlich richtig, allerdings kommt es erst spürbar zum tragen, wenn man Verzeichnisse erstellt. Bei einem leeren Dateisystem ist das Verhältnis zwischen physikalischer und dateisystem Größe wohl fest bei 1:1,0159.

[oxygen]

Das wird aber nicht passieren.
Ich stelle allerdings dagegen, dass der 2. wert berechtigt steigt und bei den grösseren Partitionen der Overhead zuwachs spürbar gemessen werden kann.

Da hast du vollkommen recht. Es sind wenn man so will 2 verschiedene Arten von Overhead, die jeweils eine anderen Messmethode erfodern.

[oxygen]

Ok, ich sehe Du kannsgt mir folgen.
Der erste "Overhead" ist statisch prozentual was auf die Formatierung zurück zu führen ist.
Man müsste jetzt mal explizit mehrer physikalische Partitionen anlegen.
Ich bin mir nicht sicher, ob es wirklich prozentual ist, oder einfach nur ein "Verschnitt" durch die Formatierung ist.

Ich habe eben auch mal ein 100GB und ein 1 TB Dateisystem angelegt und kam auf das gleiche Verhältnis 1 : 1,0159.

Mit dem bischen verschnitt den wir ja ignorierten, komme ich auf den Unterschied der zwischen iB und B liegt.

1,59% klingt zwar wenig, aber macht bei der von dir gennanten 250 GB Festplatte immerhin fast 4 GB aus.

[oxygen]

Und dieser müsste vermutlich bei allen FS identisch sein? Oder gibt es welche, die verfügbare physischen Speicher besser ausnutzen?

Siehe mein Beispiel oben. Reiserfs3.6 hatte kein Verlust bei der Formatierung. Bei weitere Dateisystemen müsste man es halt ausprobieren.