News Festplatten sollen längere Sektoren bekommen

Auf Initiative der <a href="http://www.idema.org/" target="b">IDEMA</a> (International Disk Drive, Equipment and Materials Association) sollen eventuell schon ab 2007 Festplatten mit längeren Sektoren auf den Markt kommen. War bisher über Jahrzehnte eine Sektorgröße von 512 Byte Standard, so sollen Sektoren zukünftig auf Empfehlung der IDEMA auf eine Größe von 4096 Byte verlängert werden.

Nachdem die Hersteller mit dem bisher genutzten Longitudinal Recording Verfahren bei einer Flächendichte von inzwischen über 100 Gbit pro Quadratzoll die <a href="http://de.wikipedia.org/wiki/Paramagnetismus#Superparamagnetismus" target="b">superparamagnetische Grenze</a> erreicht sahen, brauchte man zur weiteren Kapazitätssteigerung mit dem Perpendicular Recording ein neues Aufzeichnungsverfahren, um die Datendichte auch zukünftig erhöhen zu können. Allerdings ist dies mit einem hohem Aufwand verbunden, da ein neues Aufzeichnungsverfahren und eine weitere Steigerung der Datendichte immer höhere Anforderungen an die Positionierungsmechanik stellen und eine immer größere Komplexität der Schreib/Lese-Köpfe erfordern.

Eine Vergrößerung der Sektoren stellt hingegen eine vergleichsweise einfache Möglichkeit dar, die Kapazität einer Festplatte zu erhöhen. Größere Sektoren haben zunächst einmal entsprechend weniger Sektoren zur Folge. Dadurch wird u.a. die Zahl der Gaps (Abstand/Lücken), die die Sektoren voneinander trennen, reduziert. Weiterhin soll bei größeren Sektoren der für die Fehlerkorrektur benötigte Overhead relativ verringert werden.

Um entsprechende Festplatten einsetzen zu können, müssen sowohl Hostcontroller als auch BIOS mit derartigen HDDs umgehen können.

Dem Committee, das diese Vorschläge ausgearbeitet hat, gehört neben Vertretern der großen Festplatten-Hersteller auch Microsoft an. Laut der IDEMA will Microsoft eine "4K-byte sector" Unterstützung im kommenden Betriebssystem Windows Vista integrieren.


<center><img border="1" src="/news_images/sector.gif">
<i>(Quelle : <a href="http://www.hitachigst.com/hdd/ipl/oem/tech/noid.htm" target="b">Hitachi Global Storage</a>)</i></center>

<ul><li><i><b>ID Information:</b> Conventionally, space is left in each sector to identify the sector's number and location. This is used for locating the sector on the disk. Also included in this area is status information about the sector. For example, a bit is commonly used to indicate if the sector has been marked defective and remapped.</i></li><li><i><b>Synchronization Fields:</b> These are used internally by the drive controller to guide the read process.</i></li><li><i><b>Data:</b> The actual data in the sector.</i></li><li><i><b>ECC:</b> Error correcting code used to ensure data integrity.</i></li><li><i><b>Gaps:</b> One or more "spacers" added as necessary to separate other areas of the sector, or provide time for the controller to process what it has read before reading more bits.</i></li><li><i>In addition to the sectors, each containing the items above, space on each track is also used for servo information (on embedded servo drives, which is the design used by all modern units).</i></li>
<i>(Quelle : <a href="http://www.pcguide.com/ref/hdd/geom/tracksSector-c.html" target="b">The PC Guide</a>)</i></ul>

<b>Links zum Thema</b><ul><li><a href="http://www.idema.org/_smartsite/modules/local/data_file/show_file.php?cmd=download&data_file_id=1446" target="b">IDEMA Announces a New Sector Length Standard (.doc)</a></li><li><a href="http://www.pcguide.com/ref/hdd/geom/tracksSector-c.html" target="b">Sector Format and Structure (The PC Guide)</a></li><li><A HREF="http://www.hitachigst.com/hdd/research/recording_head/pr/" TARGET="b">Gegenüberstellung - Perpendicular Recording & Longitudinal Recording (Hitachi Global Storage)</A></li><li><A HREF="http://www.hitachigst.com/hdd/research/recording_head/pr/PerpendicularAnimation.html" TARGET="b">Flash Präsentation - Perpendicular Recording (Hitachi Global Storage)</A></li></ul>

und wieviel speicherplatz pro quadratzoll gewinnt man dadurch? schätze Faktor 1,5 oder 2? dann dürfte das neue maximum der HD´s bei 1TB liegen 8)

Wenn ich das richtig sehe, dann wird durch eine Vergößerung der Sektorgröße das darauf aufsetzende Dateisystem ineffektiver. Denn die minimale Clustergröße wird wohl nicht unter der minimalen Sektorengröße fesetgesetzt werden können. Dadurch dürfte bei der Ablage vieler kleiner Dateien eine Menge Speicherplat mehr gezwungenermaßen brach liegen.

Die Vergrößerung der Sektoren verursacht ja klar mehr ungenutzten Platz auf der Platte, aber wer hat denn bei einer größe von >500 MB viele kleine Dateien? Da sind auch Zugriffszeiten zweitrangig. Interessant sind eben dann echte Übertragungsraten. z.B. bei Videoschnitt wäre es schon interessant statt 50 MB/s 100 MB/s zu übertragen.

Captn-Future schrieb:

Die Vergrößerung der Sektoren verursacht ja klar mehr ungenutzten Platz auf der Platte, aber wer hat denn bei einer größe von >500 MB viele kleine Dateien? Da sind auch Zugriffszeiten zweitrangig. Interessant sind eben dann echte Übertragungsraten. z.B. bei Videoschnitt wäre es schon interessant statt 50 MB/s 100 MB/s zu übertragen.

Zum Vergrößern anklicken....

Meinst du nicht >500GB?

Momentan hat man doch meist Cluster von 4KB (bei NTFS). Wenn man das bei Festplatten mit 4KB-Sektoren beibehalten könnte, dürfte keine stärkere Fragmentierung und auch kein größerer Speicherverlust durch zu große Cluster entstehen.

SPINA schrieb:

Wenn ich das richtig sehe, dann wird durch eine Vergößerung der Sektorgröße das darauf aufsetzende Dateisystem ineffektiver. Denn die minimale Clustergröße wird wohl nicht unter der minimalen Sektorengröße fesetgesetzt werden können. Dadurch dürfte bei der Ablage vieler kleiner Dateien eine Menge Speicherplat mehr gezwungenermaßen brach liegen.

Zum Vergrößern anklicken....

Es ist korrekt, dass die minimale Clustergröße die Blockgröße des unterliegenden Mediums nicht unterschreiten kann. Da aber alle aktuellen Dateisysteme mit einer Clustergröße von standardmäßig 4kB arbeiten, ändert sich diesbezüglich überhauptnichts. Der Verschnitt bleibt gegenüber heutigen Festplatten gleich.

@Puck

Da spricht nix dagegen, dann werden pro Sektor eben mehrere Cluster gelesen. Stört niemanden, man kann ja nach wie vor mit logischen 512 Byte blöcken arbeiten. Entsprechende Änderungen in einem Treiber wären minimal, heute wird ja auch schon mit einem ziemlich großen Read Ahead gearbeitet.

ReiserFS bringt afaik aber schon jetzt pro Block mehrere Dateien unter, wenn's drauf ankommt.

Nur mal kurz zur Eklärung:

Wenn ich das richtig verstanden habe, kann man damit seine alten Festplatten nicht mehr Nutzen?

Kann ich an mein "altes" Mainboard eine Platte des neuen Typs anhängen?

mfg der BarBart

Doch doch, kannst du alles nehmen. Nur da seit vielen vielen Jahren (dürften gut über 15 sein) 512 Byte Sektoren standard sind und es bei PC Festplatten seit dem nie Modelle mit anderen Größen gegeben hat (früher gab's glaub ich ganz wenige SCSI HDDs mit anderen Sektorgrößen) ist niemand auf Sektoren anderer Größe eingestellt, und vielerorts wurden 512 Byte Sektoren fest einprogrammiert.

BarBart schrieb:

Nur mal kurz zur Eklärung:

Wenn ich das richtig verstanden habe, kann man damit seine alten Festplatten nicht mehr Nutzen?

Kann ich an mein "altes" Mainboard eine Platte des neuen Typs anhängen?

mfg der BarBart

Zum Vergrößern anklicken....

deine alte festplatte wirst da an jedem neuen mainboard/controller betreiben. wie i_hasser schon geschrieben hat, ist die sektorgröße von 512 byte seit jahrzehnten standard. entsprechend werden auch zukünftige controller mit alten platten weiterhin ohne probleme zusammenarbeiten.

ob hingegen eine neue platte mit 4096er sektoren an heutigen mainboard funktionieren werden, bleibt abzuwarten. ob es ein einfaches bios-update tut oder aber ob tatsächlich neue controller bzw. mainboards herhalten müssen, lässt sich momentan nicht sagen. auch wie es um die kompatibilität mit den diversen betriebssystem steht, bleibt fraglich. betriebssysteme, die über das bios auf die platte zugreifen, dürften eher schlechte karten haben, außer es lässt sich wie gesagt über ein bios-update regeln.

Prinzipiell ist es möglich mit den üblichen Biosfunktionen Festplatten unterschiedlicher Sektorgröße anzusprechen, beim ATA Standard müsste es eigentlich genauso sein, es wird nirgends eine Sektorgröße festgeschrieben und es existieren Funktionen, um die Sektorgröße von Geräten abzufragen. Streamer benutzen auch schon seit je her Blöcke die nicht 512 Byte groß sind.

Die Frage ist eben, wie die Programmierer die Progs geschrieben haben. Wenn seit 15 Jahren 512 Byte Blöcke normal sind (auch bei den üblichen Floppy Formaten) lässt man irgendwann die Abfrage nach der Blockgröße eben einfach weg und setzt die 512 Byte fest ein. Ist ähnlich wie mit dem Y2k Bug, niemand weis wie viel Vorsorge die Programmierer getroffen haben. Es wird sich also zeigen müssen was passiert.
Wenn sich MS zB. ordentlich an die Spezifikationen gehalten hat, wäre zumindest das Booten von windows (bis der Protected Mode geladen wird) kein Problem. Aber ich hab mir mal den disassemblierten win95 Bootsektor angeguckt, ich wette 10€ dagegen.

Danke den beiden für die Erklärung.
Wie die Juristen so schön sagen:
Diese Erklärung wirkt im Kontext erhellend.

mfg der BarBart

mich persönlich interessiert vor allem die höhere geschwindigkeit.

denn die platten sind nunmal in sachen ladezeiten oberster flaschenhals im system.
zwar gibts welche mit 10000u/min, aber ich bezahl nicht für geringfügig mehr leistung erstens mehr geld, zweitens nochmal mehr geld für mehr lüftung und drittens nochmal mehr geld für ohrstöpsel

Warum muß eigentlich immer noch jede Spur in Sektoren unterteilt sein? Es ist sicher möglich ohne weitere hardwarenahe Formatierung komplette Spuren zu befüllen. Ich komme darauf, da die Funktion (Bit/Spur) recht einfach mit dem Radius und der Spurbreite 'berechnet' werden kann und insoweit alles eindeutig und sicher definiert ist. Zumal im Falle einer solchen Lösung kleine weiteren Verluste aufgrund der Gaps (Abstand/Lücken), die die Sektoren von einander trennen auftreten können.

Mich inspirierte zu dem Gedanken der physische Ablauf beim Lesen eines Bits: Spur finden und im worstcase 2x360° lesen...

moin,

hoffe das die Mainboard Hersteller dann auch mit entsprechenden BIOS´n daher kommen und hoffe das Microsoft auch patchs zur erkennung daher kommt

sonst bringt es ja wenig wenn die andere hardware nichts erkennt.

mfg
Schmokkie

Du brauchst aber selten eine komplette Spur, außerdem gibt's eben noch CRC Daten die gespeichert werden wollen, sowie Markierungen wo ein Sektor anfängt. Wenn du die Spur nicht in Sektoren unterteilst, muss der Lesekopf erst einmal die komplette Spur lesen um die Anfangsmarkierung zu finden, dann erst können die Daten gelesen werden.
Außerdem ist es ein Problem der Genauigkeit, der Lesekopf könnte nach 270° ja schon ein Bit übersprungen haben. Bei sehr kleinen Sektoren muss der Lesekopf nur kurze Zeit ohne exakte Positionsbestimmung arbeiten.

Bei Floppies muss der Lesekopf zB. immer erst 1mal die komplette Spur lesen, weil sich der Lesekopf erstmal die Anfangsmarkierung der Spur sucht (bei Floppies fallen Zugriffszeiten ja nicht so ins Gewicht, die sind eben sowieso lahm).

Mit den CRC Daten hast du natürlich recht - hier benötigt man ein anderes System der Ablage, da muß man eine dynamische Unterbringung einbauen.

...und ja, selbstverständlich bleibt ein Startblock zur Orientierung pro Spur. Was aber wohl auszuschließen ist: Ein Lesekopf der pro 270° Drehung einen Lesefehler macht... Das wären bei 7200 rpm x 60min x 24h eine ganze Menge Schrott am Tag.

Nein, ich meinte die Synchronisation. Wenn der Lesekopf den Sektoranfang erreicht, weis er genau wo er steht. Und da die Sektoren nicht sonderlich lang sind, muss er nicht lange ohne Synchronisation auskommen - direkt danach kommt ja auch schon der nächste Sektor.

Wenn du aber nur einen Sektor machst, kann sich der Lesekopf nur 1mal pro Umdrehung synchronisieren.

Hat es nicht von IBM schon Festplatten mit variabler Sektorgrösse gegeben die nach aussen mit 512 byte Sektoren gearbeitet haben?
Die Formatierung dieser Platten hat irgendwie anders geheissen..

Weiss das noch wer von Euch?

lg
__tom

Vielleicht meinst du was anderes? Heute ist es üblich, dass die Spuren nach außen hin immer mehr Sektoren haben (so, dass auf den äußeren Spuren auch viel mehr Daten liegen).
Ganz früher war das mal anders, da lagen auf allen Spuren gleich viele Sektoren (obwohl die inneren Spuren deutlich kürzer sind als die äußeren).

i_hasser schrieb:

Vielleicht meinst du was anderes? Heute ist es üblich, dass die Spuren nach außen hin immer mehr Sektoren haben (so, dass auf den äußeren Spuren auch viel mehr Daten liegen).
Ganz früher war das mal anders, da lagen auf allen Spuren gleich viele Sektoren (obwohl die inneren Spuren deutlich kürzer sind als die äußeren).

Zum Vergrößern anklicken....

Nein, nein ich meine schon was ich schreibe
Ich meine eine variable Sektorenlänge oder waren es Sektoren ohne sync oder ähnliches.

Ich weiss es wie gesagt nicht mehr so genau.

Werde aber ein wenig herumsuchen und mich melden falls ich was finde.

lg
__tom

Allfred schrieb:

Warum muß eigentlich immer noch jede Spur in Sektoren unterteilt sein? Es ist sicher möglich ohne weitere hardwarenahe Formatierung komplette Spuren zu befüllen. Ich komme darauf, da die Funktion (Bit/Spur) recht einfach mit dem Radius und der Spurbreite 'berechnet' werden kann und insoweit alles eindeutig und sicher definiert ist. Zumal im Falle einer solchen Lösung kleine weiteren Verluste aufgrund der Gaps (Abstand/Lücken), die die Sektoren von einander trennen auftreten können.

Mich inspirierte zu dem Gedanken der physische Ablauf beim Lesen eines Bits: Spur finden und im worstcase 2x360° lesen...

Zum Vergrößern anklicken....

hat i_hasser ja schon beantwortet. aber die gaps dienen nicht nur zur abgrenzung der sektoren, sondern auch quasi als "pausenmodus" in der die platten-elektronik befehle abarbeiten kann.

i_hasser schrieb:

Stört niemanden, man kann ja nach wie vor mit logischen 512 Byte blöcken arbeiten. Entsprechende Änderungen in einem Treiber wären minimal, heute wird ja auch schon mit einem ziemlich großen Read Ahead gearbeitet.

Zum Vergrößern anklicken....

ich bin leider kein große filesystem experte. da sektoren aber immer vollständig am stück gelesen werden, bleibt die frage, was eine 512 byte einteilung dann noch beim filesystem für einen sinn macht. im umgekehrten fall (4096 logisch, 512 physikalisch) dürfte das ja unerheblich sein.

@i_hasser

Habs schon gefunden: IBM's No-ID Sektor formatting

http://www.hgst.com/hdd/ipl/oem/tech/noid.htm

Da ist zwar die Sektorlänge nicht länger sondern eigentlich nur die Sektoren näher zusammen.

Das soll angeblich bis zu 30% Platz bringen.

The performance is enhanced by the increased throughput (reduced overhead) and by the knowledge of the absolute sector locations. Power management is enhanced since there is no need to turn on the read electronics to read ID fields when searching for a sector. In this environment, No-ID with MR heads, a capacity increase of up to 30% can be achieved.

Zum Vergrößern anklicken....

leider ist nirgends eine nähere erklärung zu finden, aber bei hitachis scsi modellen ist im datenblatt eine variable sektor-größe angegeben.

http://www.hitachigst.com/hdd/support/15k147/15k147.htm

Sector size (Bytes) 512-528 (variable, 2 byte inc.)

Achso, jetzt passt das zusammen. Dann haben die das nicht gemacht um Overhead einzusparen, sondern damit man sehr einfach rausbekommt, wo ein Sektor liegt.

Normalerweise ist es nicht so, dass eine Spur weiter außen immer mehr Sektoren beinhaltet, als eine Spur weiter innen. Die HDDs werden in Zonen aufgeteilt, in denen eine konstante Zahl von Sektoren pro Spur vorhanden sind. Ich glaub übliche Werte sind so um die 10 Zonen (steht sicher im Datenblatt).

Ich könnt mir vorstellen, dass IBM diese Zonen abgeschafft hat. Die variable Blockgröße sollte dann dafür sorgen, dass man recht einfach aus der Spurnummer die Anzahl der Sektoren errechnen kann. Von der Form ergäbe das dann sowas wie (Spurnummer+n)*x = Sektoren in dieser Spur.

Das würde dem Overhead der durch die vergleichsweise recht kleine Zahl von Zonen entsteht verringern.


So könnt ich mir das jedenfalls vorstellen, vielleicht ist es auch was ganz anderes . Daneben könnte man eine leicht variable Sektorlänge auch dazu einsetzen um jede Sektorposition nur über Spurnummer und Sektor in dieser Spur errechnen zu können.
Aber an Nutzdaten trägt dann trotzdem jeder Sektor 512 Bytes.

Nochmal zu der großen Blockgröße, eine Wrapperfunktion die die 4kB Sektoren in logische 512 Byte Sektoren unterteilt könnte man in C in 4 oder 5 kurzen Zeilen realisieren, also das ist nix aufwändiges.