App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
News Festplatten sollen längere Sektoren bekommen
- Ersteller cruger
- Erstellt am
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>
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>
Rootover
Grand Admiral Special
- Mitglied seit
- 18.09.2001
- Beiträge
- 3.173
- Renomée
- 7
- Prozessor
- Athlon 64 X2 6000+
- Mainboard
- ASRock AM2XLI-eSATA2
- Kühlung
- Artic Cooling Freezer 64 Pro
- Speicher
- OCZ 6GB (2x2GB + 2x1GB)
- Grafikprozessor
- ATI Radeon HD4850
- Display
- Samsung 245b plus, 24 Zoll, 1920x1200
- HDD
- MTron SSD SLC 16GB + Samsung F1 640GB
- Optisches Laufwerk
- Asus P1604
- Soundkarte
- onboard
- Gehäuse
- Chieftec CS-601 Alu (4,5kg)
- Netzteil
- Seasonic S12 700W
- Betriebssystem
- Windows XP 64bit
- Webbrowser
- Firefox
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)
SPINA
Grand Admiral Special
- Mitglied seit
- 07.12.2003
- Beiträge
- 18.122
- Renomée
- 985
- Mein Laptop
- Lenovo IdeaPad Gaming 3 (15ARH05-82EY003NGE)
- Prozessor
- AMD Ryzen 7 3700X
- Mainboard
- ASUS PRIME X370-PRO
- Kühlung
- AMD Wraith Prism
- Speicher
- 2x Micron 32GB PC4-25600E (MTA18ASF4G72AZ-3G2R)
- Grafikprozessor
- Sapphire Pulse Radeon RX 7600 8GB
- Display
- LG Electronics 27UD58P-B
- SSD
- Samsung 980 PRO (MZ-V8P1T0CW)
- HDD
- 2x Samsung 870 QVO (MZ-77Q2T0BW)
- Optisches Laufwerk
- HL Data Storage BH16NS55
- Gehäuse
- Lian Li PC-7NB
- Netzteil
- Seasonic PRIME Gold 650W
- Betriebssystem
- Debian 12.x (x86-64)
- Verschiedenes
- ASUS TPM-M R2.0
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.
Captn-Future
Moderation DC, P3DN Vize-Kommandant
- Mitglied seit
- 16.08.2004
- Beiträge
- 8.440
- Renomée
- 316
- Standort
- VIP Lounge
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- QMC, Simap
- Lieblingsprojekt
- QMC
- Meine Systeme
- X4 940 BE
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 7 5800x
- Mainboard
- B550 Aorus Pro
- Kühlung
- bequiet Dark Rock 4
- Speicher
- 64 GB
- Grafikprozessor
- Radeon 6600xt
- Display
- HP ZR2440w 1920x1200
- SSD
- WD Black 2 TB
- HDD
- WD Blue 4 TB
- Optisches Laufwerk
- LG GSA-H10N
- Betriebssystem
- Windows 11
- Webbrowser
- FireFox
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.
Meinst du nicht >500GB?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.
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.
PuckPoltergeist
Grand Admiral Special
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.
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.
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.
BarBart
Fleet Captain Special
- Mitglied seit
- 17.05.2004
- Beiträge
- 270
- Renomée
- 3
- Standort
- im Schwabenland
- Mein Laptop
- Acer TravelMate 8371
- Prozessor
- AMD Phenom II 920
- Mainboard
- ASRock AOD790GX/128M
- Kühlung
- Arctic Cooling Freezer Xtreme
- Speicher
- 2 x 2 GB DDR II@ 800Mhz Corsair
- Grafikprozessor
- Asus R9 290
- Display
- Samsung T240
- SSD
- Crucial MX500
- HDD
- Samsung SpinPoint 750GB
- Optisches Laufwerk
- LG GGC - H20L
- Soundkarte
- Realtek ALC 890
- Gehäuse
- ThermalTake "Soprano"
- Netzteil
- BeQuiet Straight Power - 450W
- Betriebssystem
- Win7 - Home
- Webbrowser
- FF
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
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.
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.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
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.
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.
BarBart
Fleet Captain Special
- Mitglied seit
- 17.05.2004
- Beiträge
- 270
- Renomée
- 3
- Standort
- im Schwabenland
- Mein Laptop
- Acer TravelMate 8371
- Prozessor
- AMD Phenom II 920
- Mainboard
- ASRock AOD790GX/128M
- Kühlung
- Arctic Cooling Freezer Xtreme
- Speicher
- 2 x 2 GB DDR II@ 800Mhz Corsair
- Grafikprozessor
- Asus R9 290
- Display
- Samsung T240
- SSD
- Crucial MX500
- HDD
- Samsung SpinPoint 750GB
- Optisches Laufwerk
- LG GGC - H20L
- Soundkarte
- Realtek ALC 890
- Gehäuse
- ThermalTake "Soprano"
- Netzteil
- BeQuiet Straight Power - 450W
- Betriebssystem
- Win7 - Home
- Webbrowser
- FF
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
Wie die Juristen so schön sagen:
Diese Erklärung wirkt im Kontext erhellend.
mfg der BarBart
Martin Z
Vice Admiral Special
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
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
Allfred
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 7.874
- Renomée
- 98
- Standort
- Tyskland
- Prozessor
- PIII-S 1266MHz
- Mainboard
- IBM NetVista 6568 MNG
- Kühlung
- passiv, nur Gehäuselüfter
- Speicher
- 2 x 256MB PC133 CL2
- Grafikprozessor
- GF5200 DVI lowprofile
- HDD
- Seagate 7200.9 160GB
- Optisches Laufwerk
- Slimline CD
- Soundkarte
- Chipsatz i815E
- Gehäuse
- 90mm ultra thin Desktop
- Netzteil
- HIPRO 155W
- Betriebssystem
- Planet3Dnow
- Webbrowser
- FireFox
- Verschiedenes
- Leistung mit PIII 866 = 28W
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...
Mich inspirierte zu dem Gedanken der physische Ablauf beim Lesen eines Bits: Spur finden und im worstcase 2x360° lesen...
Schmokkie
Grand Admiral Special
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
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).
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).
Allfred
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 7.874
- Renomée
- 98
- Standort
- Tyskland
- Prozessor
- PIII-S 1266MHz
- Mainboard
- IBM NetVista 6568 MNG
- Kühlung
- passiv, nur Gehäuselüfter
- Speicher
- 2 x 256MB PC133 CL2
- Grafikprozessor
- GF5200 DVI lowprofile
- HDD
- Seagate 7200.9 160GB
- Optisches Laufwerk
- Slimline CD
- Soundkarte
- Chipsatz i815E
- Gehäuse
- 90mm ultra thin Desktop
- Netzteil
- HIPRO 155W
- Betriebssystem
- Planet3Dnow
- Webbrowser
- FireFox
- Verschiedenes
- Leistung mit PIII 866 = 28W
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.
...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.
Wenn du aber nur einen Sektor machst, kann sich der Lesekopf nur 1mal pro Umdrehung synchronisieren.
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
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
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).
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).
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Nein, nein ich meine schon was ich schreibeVielleicht 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).
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
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.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...
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.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.
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
@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.
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.
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.)
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.
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.
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 408
- Antworten
- 0
- Aufrufe
- 252
- Antworten
- 0
- Aufrufe
- 556
- Antworten
- 0
- Aufrufe
- 1K