Diskussion:Datenblock

Festplatten

Beim Umformulieren des Abschnitts über Festplatten und Disketten ist mir aufgefallen, dass das Geschriebene IMHO besser unter dem Stichwort Festplattengeometrie aufgehoben ist.
-- Pemu 15:53, 14. Jul 2005 (CEST)

In dem Umfang, in dem Du den Abschnitt vorgefunden hast, gehört er hier auch garnicht rein. Wenn Du Dir mal den [Unterschied zwischen meiner Version und der Version, die Du geändert hast] anschaust, wirst Du feststellen, daß da jemand sehr fleißig war - leider am falschen Ort. Ich habe jetzt erstmal basierend auf meine Version einen neuen Absatz geschrieben, und zusätzlich als Kommentar einen Hinweis eingefügt, daß dies nur ein kurzer Abriss sein soll, weitere Infos gibt es ja auf dem Link zur Festplatten-Geometrie (und jetzt sind auch Festplatte und Diskette selbst verlinkt, waren sie vorher nicht). --Bodo Thiesen 12:00, 15. Jul 2005 (CEST)

Hm, mein Vorschlag war wirklich arg kurz. Wenn ich mir das aber jetzt noch mal so recht überlege, ist doch eigentlich für eine Erklärung von "Datenblock" die Existenz einer Festplatten-Geometrie unerheblich. Interessant ist meiner Meinung nach:

• Eine Festplatte ist (unter dem Aspekt dieses Artikels) eine Ansammlung von meist 512 Byte großen Blöcken.
• Jeder dieser Blöcke kann eindeutig identifiziert/adressiert werden. Dazu gibt es verschiedene Verfahren: (z. B.) LBA und CHS (dort dann Link auf FP-Geometrie)

Von daher würde ich den ganzen Geometrie-Kram (Sektoren, Spuren, Zonen, etc.) aus diesem Artikel herauslassen. "Festplatten und Disketten sind in Datenblöcke (oder kurz Blöcke) unterteilt. Diese sind die kleinste in einem Zugriff lesbare oder schreibbare Einheit. Um einen physikalischen Datenblock zu adressieren, gibt es zwei gängige Verfahren: LBA (Logical ...) und CHS (Cyl. ...). Das LBA ist das modernere Verfahren, während für das ältere CHS-Verfahren die Kenntnis der Festplattengeometrie notwendig ist. Dateisysteme organisieren Daten i.A. nicht mehr auf der niedrigsten Ebene der Blöcke, sondern auf der nächsthöheren, den Clustern."

Was meinst Du?

-- Pemu 16:32, 18. Jul 2005 (CEST)

Keine Antwort ist auch eine Antwort. wa? --Bodo Thiesen 10:08, 6. Dez. 2006 (CET)

Nachtrag: Ich habe mir gerade mal die History durchgeschaut. Ich meine, ich bin mit der Änderung einverstanden, aber diese Änderung als "klein" zu bezeichnen ist ja wohl eine fr..., naja, in Zukunft bitte nicht mehr ;) --Bodo Thiesen 10:15, 6. Dez. 2006 (CET)

Mindestgröße eines Ethernet-Packetes

720 Bytes? Eher nicht. Eher 720 Bits, aber dann bitte noch raw und nicht coocked. macht also geteilt durch 10 72 Bytes. Ich kenne aber eher die Zahl 64 Bytes, und die hier kennen die Zahl auch. Ich hab's mal geändert, wer ein Standarddokument zur Hand hat, möge das dort bitte kurz kontrollieren, und dann hier ggf. nochmals korrigieren. --Bodo Thiesen 10:08, 6. Dez. 2006 (CET)

Noch ein Nachtrag: Eventuell stimmt auch die Zahl 72 Byte, die schonmal auf der Seite stand. --Bodo Thiesen 10:19, 6. Dez. 2006 (CET)

64Byte scheinen laut http://wiki.wireshark.org/Ethernet#head-e85f4b3e2e063114a1e48d8eaa5ad0be1eb49475 und wikipedia ethernet korrekt zu sein, allerdings packet und nicht nutzdatengröße. -- 84.61.1.106 23:57, 4. Jan. 2010 (CET)

Anmerkung zum Befehl Write Multiple

Ich konnte meinen Edit-Kommentar nicht fertigschreiben, weil ich den Edit unabsichtlich zu früh abgeschickt habe. Wenn man bei 512-Byte-Sektorten 4kB-Cluster hat, hat man trotzdem nicht immer achtmal so viele Schreibvorgänge, da es schon beim einfachsten ATA-Modus Programmed Input/Output (PIO) den Befehl "Write Multiple" gibt, siehe z.B. [1], S. 28 bzw. im PDF S. 36. --MrBurns (Diskussion) 02:52, 11. Sep. 2014 (CEST)

Und weiter bleibt alles unverständlich

Der Artikel sagt Blöcke = Sektoren und dann Cluster = Blöcke). Ergo alles drei dasselbe. Und doch soll irgendwas davon 512 Byte gross sein und das andere jetzt oder demnächst 4k. Bis dato hab ich das nie verstanden und im moment bin ich immer noch nicht schlauer. Und dann sind auch noch die Blöcke gemäss linux-fdisk offenbar 1k gross. -- itu (Disk) 12:14, 1. Jun. 2015 (CEST)

Insbesondere der Begriff "cluster" wird einfach erratisch benutzt, und er wird nie definiert. Maikel (Diskussion) 01:56, 12. Jan. 2018 (CET)

Soweit ich weiß ist ein Cluster das, was das Wort auch beschreibt: eine Ansammlung von Irgendetwas. Ein Sternencluster z.B. ist eine Ansammlung von Sternen. Bei Dateisystemen hat es sich als vorteilhaft erwiesen, wenn man die fixen Sektoren von 512 Bytes in Cluster zusammenfasst, denn dann wird der Zugriff darauf schneller, weil der Overhead sinkt. Man kann sich das so vorstellen, als wenn man sich Cornflakes kauft und diese alle einzeln mitnimmt. Wenn man die allerdings in einem Cluster kauft (also in einer Verpackung à mehrere Tausend stück), dann tut man sich leichter. Man kann dann 1 oder 2 oder gar 3 "Kornflakes-Cluster" mitnehmen – man sieht, der Overhead ist deutlich gesunken und der Einkauf, Transport und das Verstauen in der Küche funktioniert schneller und effizienter.

Dateisysteme verwenden unterschiedliche Cluster-Größen. Unter Umständen ist jedoch ein Cluster in einem Dateisystem genau die Größe eines Sektors. Und weniger als das macht auch wirklich keinen Sinn. Daher haben alle Dateisystem von Clustergrößen < 4k auf mindestens 4k umgestellt, weil auch die Hardware-Sektoren auf Speichermedien mittlerweile 4k sind. Es gibt aber auch welche, die 8k-Sektoren verwenden... Wenn das Dateisystem eine optimale Cluster-Größe für 1. das Speichermedium und 2. das verwendete Computersystem eingestellt hat, dann ist der Zugriff so effizient wie nur möglich eingestellt.

Also: ja. Block, Sektor, Cluster... sehr ähnlich, manchmal austauschbar, und es kommt (gerade bei Block) auch auf den Kontext an. (Aus Dateisystemsicht ist ein Cluster letztlich auch ein Datenblock, so wie aus Speichermedium-Hardwaresicht die Hardware-Sektorgröße und aus Betriebssystem-I/O-Sicht die Software-Sektorgröße ein einzelner Datenblock).

‣Andreas•⚖ 18:34, 12. Jan. 2018 (CET)

Die Bedeutung von Cluster wird angerissen (nächsthöhere Ebene im Dateisystem) und im übrigen verlinkt. Unter Linux wird streckenweise tatsächlich "Blöcke" sowohl für Hardware-Sektoren als auch Gruppierungen derselben verwendet – vielleicht sollte man den Widerspruch hier kurz diskutieren. --Zac67 (Diskussion) 19:05, 12. Jan. 2018 (CET)

Also ich kenne »Cluster« nur aus der Terminologie von Microsoft. Insofern frage ich mich, ob das »Cluster« in »… Clustergröße des Ur-Unix-Dateisystems …« eher dem Umstand geschuldet ist, dass der Mitautor den Dateisystemblock als Gegensatz zum Device-Block explizieren wollte. -- Pemu (Diskussion) 22:15, 12. Jan. 2018 (CET)

Ich habe mich mal versucht.

Umschön ist noch der letzte Absatz im Abschnitt, »Dateisysteme organisieren Daten üblicherweise nicht mehr auf der niedrigsten Ebene der Datenblöcke, sondern auf der nächsthöheren, der der Cluster (Terminus unter Windows; Terminus unter Linux: Blöcke). Im Gegensatz zur früher einmal üblichen geometriebasierten Adressierung wird dieses Verfahren auch blockbasierte Adressierung genannt.«

Ich verstehe den Absatz nicht. Der erste Satz bis zu m Semikolon wird von meinem eben eingefügten Absatz abgefrühstückt. Unter Linux kenne ich die Terminologie nicht. was der zweite Satz mit Clustern zu tun hat, weiß ich leider nicht.

-- Pemu (Diskussion) 00:29, 13. Jan. 2018 (CET)

Sektorgröße >512b

@Zac67: Es geht um diese Änderung.

Sind nicht die verfügbaren Sektorgrößen ebenfalls eine Hardwarevorgabe? So wird von der Hardware eine bestimmte Blockgröße vorgegeben… trifft doch auch auf eine Sektorgröße von 520, 528 etc. zu, oder nicht?

Siehe z.B. hier:

root@fileserver:~/SeaChest_Utlilites# ./SeaChest_Format_140_11923_64 --device /dev/sg2 --showSupportedFormats
==========================================================================================
 SeaChest_Format - Seagate drive utilities - NVMe Enabled
 Copyright (c) 2014-2019 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 SeaChest_Format Version: 1.4.0-1_19_23 X86_64
 Build Date: Jun 10 2019
 Today: Wed Nov 18 10:29:53 2020
==========================================================================================

/dev/sg2 - DKS2H-H4R0SS - ZAD2BNPG0000C806069Z - SCSI

Supported Logical Block Sizes and Protection Types:
---------------------------------------------------
  * - current device format
PI Key:
  Y - protection type supported at specified block size
  N - protection type not supported at specified block size
  ? - unable to determine support for protection type at specified block size
Relative performance key:
  N/A - relative performance not available.
  Best
  Better
  Good
  Degraded
--------------------------------------------------------------------------------
 Logical Block Size  PI-0  PI-1  PI-2  PI-3  Relative Performance  Metadata Size
--------------------------------------------------------------------------------
                512     Y     N     N     N                   N/A            N/A
                520     Y     N     N     N                   N/A            N/A
*               528     Y     N     N     N                   N/A            N/A
--------------------------------------------------------------------------------
NOTE: Device is not capable of showing all sizes it supports. Only common
      sizes are listed. Please consult the product manual for all supported
      combinations.

Ich habe es daher nochmals umformuliert, und zwar in: So werden von der Hardware bestimmte Blockgrößen vorgegeben…

Ich hoffe, dass das so passt. ‣Andreas•⚖ 12:17, 25. Mai 2022 (CEST)

P.S. Mein Fehler: Das sind eigentlich keine Sektorgrößen, sondern abermals logische Blockgrößen. Die Sektoren auf dem physischen Medium bleiben dadurch ja unverändert - es ist abermals der Controller des Speichermedium, der Hardware, in diesem Fall also einer SAS-Festplatte oder -SSD, der eine Low-Level-Formatierung in Form von unterschiedlichen logischen Blockgrößen ermöglicht. Wie das physikalisch auf dem Medium abgebildet ist – auf den Sektoren – ist Controllersache und vermutlich auch Betriebsgeheimnis des jeweiligen Herstellers... ‣Andreas•⚖ 12:24, 25. Mai 2022 (CEST)

Vorlage:Re Tatsächlich werden die physischen Sektoren in verschiedenen Größen formatiert (s. en:Hard disk drive#Enterprise and_business segment und können bei diversen Modellen umformatiert werden (Quelle dazu kann ich sicher liefern). Dass das nicht nur logisch umdefiniert wird ergibt sich aus der Tatsache, dass die nutzbare Kapazität (Anzahl der Sektoren) sich beim Umformatieren ändert. --Zac67 (Diskussion) 13:05, 25. Mai 2022 (CEST)

Hm...

Dass sich die Kapazität ändert, davon bin ich irgendwie ausgegangen. Aber warum ändert sich auch die Anzahl der Sektoren?

Physisch sind Sektoren ja ohnehin viel größer als nur 512 Bytes (oder eben 520, etc...), weil die Daten auf der Festplatte niemals 1:1 das enthalten können, was im logischen Sektor bzw. dem logischen Datenblock des Datenträgers enthalten ist, sondern benötigt immer zusätzliche (Verwaltungs-)Informationen. Als Beispiel soll hier das Low-Level-Format einer Floppy-Diskette dienen: ein Low-Level-Sektor darauf teilt sich in ein Adressfeld und ein Datenfeld. Im Adressfeld, das immer mit einem Header (bestehend aus lauter Nullen) beginnt, finden sich neben der jeweiligen Sektoradresse (der CHS-Adresse) auch u.a. Prüfbits und die Sektorlänge. Im Datenfeld sind ebenfalls weitere Daten enthalten: neben einem Data Address Mark (kurz DAM, welcher den Status des Datenblocks festlegt, z.B. den Sektor als "defekt" markiert) finden sich darin auch noch eine Checksumme (CRC), sowie natürlich der logische Sektor von 128 bis 1024 Byte, je nach Formatierung. Ein Low-Level-Sektor ist also immer größer als der Datenblock, der als "logischer Sektor" von einer Software gelesen wird bzw. logisch vom Laufwerk erhalten wird. Aber auch (Nicht-)Daten sind zu finden, die der Mechanik helfen, den jeweiligen Sektor zu finden: der "Gap" ist eine Lücke jeweils zwischen zwei Sektoren.^ref U.a. um diese Metadaten (oder Nicht-Daten) zu vermindern wurde ja gerade 4k/Advanced Format geschaffen, denn bei 4096 Bytes je logischem Sektor ist der reale Datenverbrauch auf dem Speichermedium deutlich geringer. (Angefangen bei den viel weniger vorhandenen Lücken aka Gaps)...

Es wäre jetzt zu prüfen, ob die Sektoren bei einer geänderten Sektorgröße (logischen Blockgröße!) von 520 Bytes und mehr tatsächlich auch die Low-Level-Formatierung verändern, oder ob einige der zusätzlichen Daten dafür geopfert werden, den logischen Sektor etwas größer zu machen. Dann müsste aber die Anzahl der Sektoren gleich bleiben, die Kapazität würde sich aber ändern.

‣Andreas•⚖ 13:42, 25. Mai 2022 (CEST)

Ja, das betrifft die Low-Level-Formatierung. Als Nutzgröße werden üblicherweise 512 Bytes verwendet, der Rest für Metadaten. Da mit 512 Bytes Sektorgröße mehr Sektoren auf die Platte passen, ist da die Nutzkapazität am größten. Ich hatte mal das Problem als ich eine gebrauchte SAS-Platte gekauft hatte, die auf 520 Bytes oder so formatiert war und deshalb zu klein für das Array, wo sie rein sollte. Ich habe die dann auf 512B umformatiert (dauerte etwas), und dann ging's. Das ist aber etliche Jahre her, ich weiß nicht mehr wie ich das gemacht habe... --Zac67 (Diskussion) 16:22, 25. Mai 2022 (CEST)

Habe das hier gefunden: The IBM 59E5 600GB Disk Drive is supported in SFF-3 SAS bays and formatted for 4096 byte sectors. If reformatted to 4224 byte sectors, capacity would be 571 GB for a different IBM OS type requirement.^ref

Außerdem das: 4.2.3 SCSI disk units under AIX 5L – When disk units are discovered under AIX 5L, they are assigned a device name using either the hdisk form, or the pdisk form: pSeries disk units are formatted to 512 bytes per sector by default, and receive a hdisk name. … iSeries disk units are formatted to “iSeries” 522 bytes per sector by default, and receive a pdisk name.^PDF
Bei diesem PDF über i5/OS und AIX 5L ist in den Diagrammen auf den Seiten 86 und 88 (im PDF die Seiten 98 und 100) jeweils ein Hardware-RAID-Controller zu sehen, der die 522-Bytes-pro-Sektor-pdisks für das System jeweils in 512-Bytes/Sektor-hdisks umwandelt. Was in den zusätzlichen 10 Byte pro Sektor gespeichert wird, ist mir nicht ganz klar, obwohl es vermutlich als Cache fungiert: Any i5/OS specific disk units that are attached to hardware RAID controllers, should not be reformatted from 522 bytes/sector to 512 bytes/sector. Doing so will disable any, and all, hardware cache for the DASD controller. This will result in a significant performance degradation for the AIX 5L partition.^{siehe PDF, S. 19 (PDF-Seite 31)}

Möglicherweise werden aber auch Konfigurationen unterstützt, in denen ein System eine 520 Byte Sektorgröße direkt verwenden kann: Translation from 520 byte blocks to 512 byte blocks – … IBM i performs the following change of the data layout to support 512 byte blocks (sectors) in external storage: for every page (8 * 520 byte sectors) it uses additional 9th sector; it stores the 8-byte headers of the 520 byte sectors in the 9th sector, and therefore changes the previous 8* 520-byte blocks to 9* 512-byte blocks. The data that was previously stored in 8 * sectors is now spread across 9 * sectors, so the required disk capacity on V7000 is 9/8 of the IBM i usable capacity. Vice versa, the usable capacity in IBM i is 8/9 of the allocated capacity in V7000. … Therefore, when attaching a Storwize V7000 to IBM i, whether through vSCSI, NPIV or native attachment this mapping of 520:512 byte blocks means that you will have a capacity ‘overhead’ of being able to use only 8/9ths of the effective capacity.^ref (Anmerkung: Offenbar übernimmt diese Aufgabe unter AIX VIOS, was für Virtual I/O Server steht...)

Die meisten anderen Betriebssysteme können jedoch nicht mit anderen Blockgrößen als 512 oder einem Vielfachen davon (4096, Advanced Format) umgehen. 520 Bytes/Sektor lässt sich etwa mit Linux nicht auslesen.^Bsp.

Was mir aber immer noch unklar ist, ist, ob nun die Sektoranzahl gleich bleibt oder sich ändert. Die oben Erwähnte "Transition" ändert ja die 520B Sektorgröße nicht, weshalb ein System, das nur 512B verwendet, mit der "Transition"-Lösung auch 9/8 (also um ein Achtel mehr!) Speicherplatz erhält. (Umgekehrt wenn ein 512B-Speichermedium auf einem 520B-System genutzt wird: dieses verliert 8/9 der Kapazität (also ein Neuntel weniger). Was aber, wenn man die Festplatte/SSD neu low-level-formatiert? Ist die Anzahl der Blöcke (Sektoren) dann eine andere? Warum?

‣Andreas•⚖ 19:48, 25. Mai 2022 (CEST)

Ja, das passt. Du kannst sehen, dass bei größeren Sektoren die (Nutz-)Kapazität sinkt – das liegt an der Änderung der Sektorenanzahl. --Zac67 (Diskussion) 19:53, 25. Mai 2022 (CEST)

Ich habe jetzt mal die Rohdaten aus dieser Quelle hergenommen und ein wenig herumgerechnet:

Logical Block Size: 512
Last LBA:           7814037168
Capacity:           4.000.787.030.016 bytes

Probe: 4000787030016 ÷ 512 = 7814037168

Logical Block Size: 528
Last LBA:           7438330376
Capacity:           3.927.438.438.528 bytes

Probe: 3927438438528 ÷ 528 = 7438330376

Ergo: Bei größerer Blocksize werden es weniger Blöcke, aber nicht direkt proportional, denn: 4000787030016 ÷ 528 = 7577248162,90 → bei gleicher Kapazität mit 528B statt 512B müsstes es rund 7577248163 Blöcke (Last LBA) sein; da es aber nur 7438330376 sind, sinkt die Kapazität, obwohl pro Block mehr Daten gespeichert werden.

Die Logik ist aber für mein Verständnis umgekehrt, denn wenn die Blockgröße nach oben verändert wird, werden normalerweise die Metadaten in den Sektoren verringert! 4096B hat daher mehr Kapazität für die logischen Blöcke zur Verfügung als 512B, weil im Sektor jeweils weniger Metadaten (per-Sektor: DAM, CRC, Gap etc...) gespeichert werden müssen.

Es hätte auch so sein können, dass die Metadaten in den Sektoren selbst verändert werden: bei gleicher Anzahl an Low-Level-Sektoren wären dann mehr Bytes pro Sektor an Nutzdaten = logischer Sektor verfügbar gewesen. (Wenn etwa die CRC im Low-Level-Sektor weggelassen wird, oder andere "Optimierungen" der Metadaten vorgenommen werden.) Dann wäre die Anzahl der Sektoren identisch, und die Kapazität würde direkt proportional mit der Blockgröße ansteigen. Beispielsweise so: 7814037168 × 520 = 4.063.299.327.360 bytes (4,06 GB/3,695 GiB) – aber so ist es ja nicht...

Was dennoch übrig bleibt, ist folgende Feststellung: Wären die (logischen) Blöcke gleich der Anzahl der Low-Level-Sektoren, die eine größere Blockgröße (block size) haben, dann müsste die Kapazität eigentlich steigen. (Grund: weniger Sektoren = weniger Metadaten → mehr Speicherplatz für Nutzdaten in Form von logischen Blöcken.) Daraus ergibt sich die Frage: Warum ist das aber nicht so? Oder: Wie ist es denn nun wirklich?

‣Andreas•⚖ 15:27, 28. Mai 2022 (CEST)