Wo bleiben die 6TB Festplatten? Oder: Das Ende von Moores Law für HDs.

Zuletzt bearbeitet:
Die sollten sich lieber was einfallen lassen, sonst ziehen irgendwann die SSD Hersteller vorbei und Magnetplatten werden überflüssig.
 
[MTB]JackTheRipper;4587987 schrieb:
Die sollten sich lieber was einfallen lassen, sonst ziehen irgendwann die SSD Hersteller vorbei und Magnetplatten werden überflüssig.

Ist das nicht eh nur eine Frage der Zeit? Gäbe es, gleichen Preis/GB für HDD und SSD vorausgesetzt, noch einen Grund eine HDD zu kaufen?
 
Ja die Ausfallrate.
 
Kann man schlecht sagen, ja. Aber aktuell sieht es eben so aus.
Wenn die 60TB Ende des Jahrzehnts erreicht werden (sollten), werden die SSDs dennoch hinterher hinken. Die Datendichte ist da einfach nicht hoch genug. Aktuell ist die Kapazität einer HDD etwa dreimal so hoch ggü. einer SSD bei gleichem Formfaktor. Und da nutzt man schon aktuelle Fertigungsprozesse. Ich würde mir nicht wieder 5 1/4" Geräte in den Rechner schrauben wollen, nur um die gleiche Menge Daten speichern zu können. Daher denke ich, SSDs werden ihren Einsatz dort haben, wo es auf Geschwindigkeit ankommt. Als Datengräber werden mMn. auf absehbare Zeit weiterhin HDDs verwendet.
 
Das Problem ist eher dass große SSDs selbst im 6.5nm Prozess nur 8-16 TB groß wären, die Zugriffszeiten aber wieder ansteigen werden.


Die Ausfallrate aufgrund von Zellermüdung ist in der Praxis nicht relevant, zumindest mit aktuellen SSD-Generationen (Hitachi Ultrastar z.B.die locker 7PB Host Writes verkraften)
Anbei noch eine Quelle zum Thema:
http://www.storagesearch.com/ssdmyths-endurance.html

Ausserdem gibts da noch viel Verbesserungpotential: wenn man einen Weg findet, die Elektronen in den Zellen mit niedrigeren Spannungen "einzuschießen", nimmt auch die Abnutzung der Zelle ab.


Aber schaun wi rmal wie Racetrack sich entwickelt.
 
Zuletzt bearbeitet:
Ich bezog mich nicht auf die Zellermüdung. Eher auf die Geräte, die ohne Vorwarnung am nächsten Tag, nach einer Woche oder einem Monat einfach aussteigen. Das darf bei den anvisierten Kapazitäten einfach nicht passieren. Hier haben HDDs auch noch den Vorteil, dass man eine Platine tauschen kann.
 
Gut da stimme ich dir zu, die Firmwares der Controller sind gelinde gesagt eine Katastrophe. Solche Fehler dürfen nicht passieren!
 
CDs hab ich gerade keine da, um die Angabe 700mb(=millibit :D ) zu überprüfen.
Aber immer wenn ich DVDs brenne, passen da genau die angegebenen 4,7GB, also um die 4,3GiB drauf. Ergo exakt wie bei Festplatten und nicht etwa anders.
Bei der CD passen 700 MiB (703 MB) drauf.
Bei der DVD passen 4,7 GB (4,377 GiB) drauf.

Und noch viel lustiger ist es bei Disketten: Die 1,44 sind weder MiB noch MB, sondern genau 1000*1024*1,44 Bytes ;D
 
Tatsächlich waren es übrigens 1440 KB, was auf 2 Seiten der Diskette mit je 80 Spuren zu je 16 Sektoren mit je 512 Byte pro Sektor begründet ist.
 
Zuletzt bearbeitet:
Tatsächlich passen auf eine 700MB CD deutlich mehr Daten. 80min entsprechen nämlich 807,5MB, die auf eine Audio CD passen (16Bit Stereo 44.1kHz -> 1.411 kbit/s). Irgendwo meine ich gelesen zu haben, dass bei einer Daten CD die Differenz für die Datenintegrität genutzt wird. Und ein Teil geht auch fürs Dateisystem drauf.
 
The reason why an AUDIO CD holds more data/sector lays in the fact that it uses the complete 2352 bytes to store AUDIO in one sector. This means that an Audio-Byte is per default corrupt as there is no CRC checking. Due to hardware datacorrection these errors are not heard.
This method can not be used for a Data-Bytes as the data would be corrupt. To fix this problem a DATA sector contains both Data and CRC-CCITT Information.
CRC-CCITT is a 16 bit EDC (Error Detecting Code). For every byte of data a 16 bit CRC code is calculated, resulting in 128 CRCs, 16 bits each. These CRCs, therefore, take up 256 bytes of the 2352 bytes available. The remaining 48 bytes are reserved for future use. This leaves 2048 bytes available for actual Data.
http://www.cdmediaworld.com/hardware/cdrom/cd_techinfo.shtml
 
Ja beschreibt nichts anderes, als das was ich geschrieben hab. Lediglich in Bezug auf 650MB CDs.

Änderung der Quelle.
 
Zuletzt bearbeitet:
Nur etwas genauer und mit Quelle ;-)

Es gab ja auch MODE-2 CDs die die vollen 2352 Bytes genutzt haben z.B. Super-Video-CDs. Auch hier aber das Problem: war ein Kratzer auf der CD gabs Datenmüll. Bei Audio / Video ist das natürlich nicht so schlimm, bei Programmcode allerdings schon ;-)
 
Das ganze erinnert etwas an:

* Fuder: Das Fuder wurde bis 1862 als Gewichtseinheit im Bergbau, v.a. im Eisenerzbergbau benutzt. Das Gewicht eines Fuders schwankte je nach Eisengehalt. Es betrug in
o Berggießhübel: etwa 22 Zentner
o Johanngeorgenstadt: je nach Bergwerk zwischen 16 7/8 Zentner 5 Pfund und 25 5/8 Zentner 7 1/2 Pfund
o Schwarzenberg: je nach Bergwerk zwischen 16 7/8 Zentner und 24 3/8 Zentner 8 3/4 Pfund
o Eibenstock: je nach Bergwerk zwischen 16 1/4 Zentner 10 Pfund und 16 1/8 Zentner 11 1/4 Pfund

* 1 Pfund (Krämergewicht) = 16 Unzen = 32 Lot = 128 Quentchen ? 467,2 Gramm
* 1 Pfund (Apothekergewicht) = 12 Unzen = 24 Lot ? 350,4 Gramm


usw usw usw (Quelle Wiki)

Vielleicht wird es doch noch eine verbindliche Richtline geben, in welcher Art und Weise und aufgrund welcher Berechnungsgrundlagen Datenträgergrößen (und Vergleichbares) anzugeben sind. Bis dahin können wir munter rechnen und mitunter raten oder uns im Forum beschimpfen weil nicht jeder ein Mathecrack ist ;D *lol*

PS: sorry für OT, der Thread weicht vom Thema ab ...
 
Si-Einheiten sind doch eigentlich bereits verbindlich, nur werden sie oft einfach ignoriert. In manchen Bereichen sind ja sogar die längst veraltet geglaubten Einheiten wieder auf dem Vormarsch. Allen, die noch in Zoll rechnen, würde ich am liebsten einen Zollstock in den ... äh, lassen wir das.
 
Si-Einheiten sind doch eigentlich bereits verbindlich, nur werden sie oft einfach ignoriert.
Zum Beispiel von einem Unternehmen aus Redmond, das auch sonst lieber eigene Quasi-Standards durchdrückt anstatt vorhandene offene Standards zu implementieren. :) Und dann beschweren sich alle, weil sie von den Festplattenherstellern "betrogen" werden...
 
Zum Beispiel von einem Unternehmen aus Redmond, das auch sonst lieber eigene Quasi-Standards durchdrückt anstatt vorhandene offene Standards zu implementieren. :) Und dann beschweren sich alle, weil sie von den Festplattenherstellern "betrogen" werden...
Pff, als ob die Linux-Welt da irgend etwas besser machen würde. :]
 
Es gibt auch schon lange eine ISO-Norm zum Datum der Form YYYY-MM-DD aber nutzen tut die auch keiner....
 
Warum auch? Da hat sich jemand was genau gegensätzlich zum alltäglichen Gebrauch ausgedacht.

Wir sagen ja: "Der vierzehnte siebte zweitausendzwölf". Der Standard notiert "Zweitausend12 sieben vierzehn"

Das ist nur mal wieder das amerikanische Zentralismusverständnis.


Okay, es ergibt schon Sinn wenn man Dokumente nach Datum ordent weil sich aus 2012-07-14 prima eine aufsteigende Formatierung ergibt. Aber ansonsten...
 
Genau, wie man es LIEST ist doch egal, du kannst ja immer noch den 14.7.2012 aus 2012-07-14 herauslesen.. aber sortieren kann man das Feld eben als Text nicht, sondern nur wenn man es als Datum interpretiert.
 
Nur weil sich ein Sesselpupser ausgedacht hat, das Datum so schrieben lassen zu müssen ist es noch lange nicht üblich es so zu machen. Aber wenn man danach geht sollte man auch nicht mehr Dreihundertzweiundfünfzig sagen sondern Dreihunderet fünfzig und zwei.
 
Zurück
Oben Unten