| Zeile 52: | Zeile 52: | ||
::Warum sollte sich die Sektorgröße für die SW ändern? Damit machen es sich die HDD-Hersteller auch nicht einfacher. Ich denke die werden das auch in Zukunft vor der SW verstecken um die physikalische Sektorgröße nach eigenen Bedürfnissen flexibel anpassen zu können. Vergleich doch mal mit den Flash-Basierten Speichermedien, dort gibt es intern etliche verschiedene Sektorgrößen (bedingt durch die Menge an Daten die auf einmal gelöscht oder auf einmal geschrieben werden können, sind beides übrigens verschiedene Mengen). Wenn die HDD-Hersteller anfangen würden die Sektorgröße nach aktueller Mode (Fertigungstechnologie usw.) zu ändern dann müsste jede SW die direkt mit Massenspeichern arbeitet flexibel damit umgehen können und das ist von einem Boot-Loader kaum zu erwarten und vom Code im Boot-Sektor/MBR erst recht nicht. Daher bin ich der Meinung das für einen Boot-Loader und anderen Code noch davor die physikalische Sektorgröße völlig irrelevant ist (der marginale Performance-Verlust ist wohl ziemlich uninteressant). Erst die Massenspeicher-Verwaltungsprogramme (fdisk usw.) und die Datei-System-Designer bzw. die zugehörigen Formatierungstools sollten die physikalische Sektorgröße kennen und beachten.<br />Das mit den 4kByte-Sektoren hab ich auch noch in anderen Wiki-Artikeln gesehen. Ich wollte eigentlich nur wissen warum dieser Umstand überhaupt so deutlich angesprochen wird (ich sehe dazu eben keine Notwendigkeit). Wenn meine Einwände unbegründet sind dann löscht bitte einfach diese Diskussion. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 19:34, 13. Apr. 2010 (CEST) | ::Warum sollte sich die Sektorgröße für die SW ändern? Damit machen es sich die HDD-Hersteller auch nicht einfacher. Ich denke die werden das auch in Zukunft vor der SW verstecken um die physikalische Sektorgröße nach eigenen Bedürfnissen flexibel anpassen zu können. Vergleich doch mal mit den Flash-Basierten Speichermedien, dort gibt es intern etliche verschiedene Sektorgrößen (bedingt durch die Menge an Daten die auf einmal gelöscht oder auf einmal geschrieben werden können, sind beides übrigens verschiedene Mengen). Wenn die HDD-Hersteller anfangen würden die Sektorgröße nach aktueller Mode (Fertigungstechnologie usw.) zu ändern dann müsste jede SW die direkt mit Massenspeichern arbeitet flexibel damit umgehen können und das ist von einem Boot-Loader kaum zu erwarten und vom Code im Boot-Sektor/MBR erst recht nicht. Daher bin ich der Meinung das für einen Boot-Loader und anderen Code noch davor die physikalische Sektorgröße völlig irrelevant ist (der marginale Performance-Verlust ist wohl ziemlich uninteressant). Erst die Massenspeicher-Verwaltungsprogramme (fdisk usw.) und die Datei-System-Designer bzw. die zugehörigen Formatierungstools sollten die physikalische Sektorgröße kennen und beachten.<br />Das mit den 4kByte-Sektoren hab ich auch noch in anderen Wiki-Artikeln gesehen. Ich wollte eigentlich nur wissen warum dieser Umstand überhaupt so deutlich angesprochen wird (ich sehe dazu eben keine Notwendigkeit). Wenn meine Einwände unbegründet sind dann löscht bitte einfach diese Diskussion. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 19:34, 13. Apr. 2010 (CEST) | ||
:::Um es endlich mal auf den Punkt zu bringen ... soweit mir bekannt ist, besitzen diese 4k-Platten eine Abwärtskompatiblität zu 512byte-Platten, d.h. sie unterstützen auch die Adressierung für 512-Bytes-Sektoren (neben 4k-Sektoren). Wobei es mir hier geht ist, wie das BIOS den Boot-Sektor laden wird, kompatible mit 512 Bytes oder volle physikalische 4k?? Sollte letzteres der fall sein, bekommt man den ganzen Code rein und brauch in nicht splitten. Der Bootloader brauch nicht angepasst werden, wenn man genau an die Spezifikation eines Dateisystem bspw. FAT hält. FAT enthält im BIOS-Parameter-Block auch die Größe eines Sektors, hiermit ist die physikalische Größe gemeint. Und genau mit dieser sollte gerechtnet werden, nicht mit Konstanten. Kurz gesagt, booten von einem USB-Stick sollte damit kein Problem sein. -- [[Benutzer:ScollPi|ScollPi]] 21:01, 13. Apr. 2010 (CEST) | :::Um es endlich mal auf den Punkt zu bringen ... soweit mir bekannt ist, besitzen diese 4k-Platten eine Abwärtskompatiblität zu 512byte-Platten, d.h. sie unterstützen auch die Adressierung für 512-Bytes-Sektoren (neben 4k-Sektoren). Wobei es mir hier geht ist, wie das BIOS den Boot-Sektor laden wird, kompatible mit 512 Bytes oder volle physikalische 4k?? Sollte letzteres der fall sein, bekommt man den ganzen Code rein und brauch in nicht splitten. Der Bootloader brauch nicht angepasst werden, wenn man genau an die Spezifikation eines Dateisystem bspw. FAT hält. FAT enthält im BIOS-Parameter-Block auch die Größe eines Sektors, hiermit ist die physikalische Größe gemeint. Und genau mit dieser sollte gerechtnet werden, nicht mit Konstanten. Kurz gesagt, booten von einem USB-Stick sollte damit kein Problem sein. -- [[Benutzer:ScollPi|ScollPi]] 21:01, 13. 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) | ||