| Zeile 60: | Zeile 60: | ||
Ich hab gerade, in der aktuellen c't ([http://www.heise.de/ct/inhalt/2010/09/132/ hier]), gesehen das die Hersteller tatsächlich planen das die neuen HDDs sich mit 4 kByte Sektorgröße melden sollen. Aufgrund der umfangreichen und kaum abschätzbaren Folgen hätte ich nie damit gerechnet das die sich das tatsächlich trauen. Zumindest dafür das die wirklich die heilige Kuh der Kompatibilität zum Schlachter führen gibt es meinen Respekt. Vor wenigen Jahren wurde bei der Festlegung des SD-'''HC'''-Standards noch auf 512 Byte Sektorgröße gesetzt, obwohl damals schon kein Flash-Chip mehr verfügbar war der noch 512 Byte als physikalische Sektorgröße unterstützt (zumindest beim lesen, gelöscht und geschrieben wird eh in größeren Einheiten). Aktuell sind bei Flash-Chips 2 kByte und demnächst wohl auch 8 kByte. Und bei den SSDs, wo die Daten über mehrere Flash-Chips verteilt werden (wahrscheinlich mit einer Art RAID 0), dürften die Hersteller sicher gerne noch größere Sektoren wollen.<br />Worauf ich hinaus will ist das von variablen Sektorgrößen eine enorme Menge an Software betroffen ist. Gerade viele kleine Programme für Embedded-Systeme oder andere Hobby-Projekte dürften darunter leiden. Wer will schon einen richtigen UDF-Dateisystem-Treiber in einen Mikrocontroller quetschen nur weil es auf dem PC kein Format-Tool gibt das auf der neuen HDD noch mit FAT formatieren will (ich weiß das FAT theoretisch mit vielen Sektorgrößen umgehen kann aber ob Microsoft da mitspielt ist IMHO fraglich).<br />Von einer geänderten Sektorgröße ist u.a. das BIOS betroffen, im c't-Artikel ist dazu ausgeführt das damit wohl ein weiterer Vorschub für EFI eintritt (was prinzipiell sehr zu begrüßen ist), was wohl wieder Auswirkungen auf Boot-Loader usw. hat. Ich frage mich an welches Offset dann die 0xAA55-Signatur kommt. Auch viele Dateisystem-Treiber dürften davon betroffen sein, ich glaube nicht das man alle Dateisystem-Strukturen (iNodes usw.) einfach so auf größere Sektoren skalieren kann (FAT als primitiv-Dateisystem ist da noch ein äußerst simples Beispiel). Auf Grund dieser massiven Auswirkungen hätte ich bis heute Früh nie geträumt das die HDD-Hersteller wirklich die logische Sektorgröße ändern würden, Gründe dafür gibt es eigentlich schon länger aber bis jetzt hat sich das noch keiner getraut.<br />Mit dieser Info sollten wir mal überlegen was noch alles betroffen ist und in den betreffenden Wiki-Artikeln passende Hinweise geben.<br />Sorry das ich erst in die andere Richtung gewettert habe. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 22:29, 14. Apr. 2010 (CEST) | Ich hab gerade, in der aktuellen c't ([http://www.heise.de/ct/inhalt/2010/09/132/ hier]), gesehen das die Hersteller tatsächlich planen das die neuen HDDs sich mit 4 kByte Sektorgröße melden sollen. Aufgrund der umfangreichen und kaum abschätzbaren Folgen hätte ich nie damit gerechnet das die sich das tatsächlich trauen. Zumindest dafür das die wirklich die heilige Kuh der Kompatibilität zum Schlachter führen gibt es meinen Respekt. Vor wenigen Jahren wurde bei der Festlegung des SD-'''HC'''-Standards noch auf 512 Byte Sektorgröße gesetzt, obwohl damals schon kein Flash-Chip mehr verfügbar war der noch 512 Byte als physikalische Sektorgröße unterstützt (zumindest beim lesen, gelöscht und geschrieben wird eh in größeren Einheiten). Aktuell sind bei Flash-Chips 2 kByte und demnächst wohl auch 8 kByte. Und bei den SSDs, wo die Daten über mehrere Flash-Chips verteilt werden (wahrscheinlich mit einer Art RAID 0), dürften die Hersteller sicher gerne noch größere Sektoren wollen.<br />Worauf ich hinaus will ist das von variablen Sektorgrößen eine enorme Menge an Software betroffen ist. Gerade viele kleine Programme für Embedded-Systeme oder andere Hobby-Projekte dürften darunter leiden. Wer will schon einen richtigen UDF-Dateisystem-Treiber in einen Mikrocontroller quetschen nur weil es auf dem PC kein Format-Tool gibt das auf der neuen HDD noch mit FAT formatieren will (ich weiß das FAT theoretisch mit vielen Sektorgrößen umgehen kann aber ob Microsoft da mitspielt ist IMHO fraglich).<br />Von einer geänderten Sektorgröße ist u.a. das BIOS betroffen, im c't-Artikel ist dazu ausgeführt das damit wohl ein weiterer Vorschub für EFI eintritt (was prinzipiell sehr zu begrüßen ist), was wohl wieder Auswirkungen auf Boot-Loader usw. hat. Ich frage mich an welches Offset dann die 0xAA55-Signatur kommt. Auch viele Dateisystem-Treiber dürften davon betroffen sein, ich glaube nicht das man alle Dateisystem-Strukturen (iNodes usw.) einfach so auf größere Sektoren skalieren kann (FAT als primitiv-Dateisystem ist da noch ein äußerst simples Beispiel). Auf Grund dieser massiven Auswirkungen hätte ich bis heute Früh nie geträumt das die HDD-Hersteller wirklich die logische Sektorgröße ändern würden, Gründe dafür gibt es eigentlich schon länger aber bis jetzt hat sich das noch keiner getraut.<br />Mit dieser Info sollten wir mal überlegen was noch alles betroffen ist und in den betreffenden Wiki-Artikeln passende Hinweise geben.<br />Sorry das ich erst in die andere Richtung gewettert habe. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 22:29, 14. Apr. 2010 (CEST) | ||
:Dann bist du ja weiter mit dem Lesen als ich. Na jedenfalls, die Frage, wo die 0xAA55-Signatur stehen wird, ist doch logisch ... immer die letzten zwei Bytes des physikalischen Sektor. Bsp. Daten-CDs haben 2048 Bytes große Sektoren und da steht eben die Signatur an Offset 0x07FE, also am Ende des Sektors. Bei 4k-Platten wird es also bei 0x0FFE sein. Aber so idiotisch es auch klingt, FAT kann (sollte, vom Treiber abhängig) 4k-Sektoren verwalten. -- [[Benutzer:ScollPi|ScollPi]] 22:48, 14. Apr. 2010 (CEST) | :Dann bist du ja weiter mit dem Lesen als ich. Na jedenfalls, die Frage, wo die 0xAA55-Signatur stehen wird, ist doch logisch ... immer die letzten zwei Bytes des physikalischen Sektor. Bsp. Daten-CDs haben 2048 Bytes große Sektoren und da steht eben die Signatur an Offset 0x07FE, also am Ende des Sektors. Bei 4k-Platten wird es also bei 0x0FFE sein. Aber so idiotisch es auch klingt, FAT kann (sollte, vom Treiber abhängig) 4k-Sektoren verwalten. -- [[Benutzer:ScollPi|ScollPi]] 22:48, 14. Apr. 2010 (CEST) | ||
| + | ::Dazu möchte ich gerne die FAT-Spezifikation zitieren: "There is one other important note about Sector 0 of a FAT volume. If we consider the contents of the sector as a byte array, it must be true that sector[510] equals 0x55, and sector[511] equals 0xAA. | ||
| + | |||
| + | NOTE: Many FAT documents mistakenly say that this 0xAA55 signature occupies the “last 2 bytes of the boot sector”. This statement is correct if — and only if — BPB_BytsPerSec is 512. If BPB_BytsPerSec is greater than 512, the offsets of these signature bytes do not change (although it is perfectly OK for the last two bytes at the end of the boot sector to also contain this signature)." --[[Benutzer:Sur3|Sur3]] | ||
== DS auf 7C0h ist ganz schlecht ... == | == DS auf 7C0h ist ganz schlecht ... == | ||