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 einen alternativen Browser verwenden.
Es gab ja vor einem Jahrzehnt ein Update von 512byte zu 4kb . Weniger ECC und Adressen oder so werden eingespart.
1.) Bringt mir es effektiv etwas wenn ich statt 4kB, 64kB verwende?
Spare ich mir dann ~5% (für die Metadaten) * 11 (statt 12 4kB Sektoren, 1x 64kB) pro Datei. Was dann auf eine 10TB Platte mit nur Dateien >5GB zB. einen zusätzlichen Film bedeuten kann? Oder würde mir das nichts bringen?
Zudem wie sieht es dann physikalisch aus? Wird bei einer neuen Platte trotzdem alles auf 4k unterteilt oder nicht?
2.) Was macht der ECC der HDD?
Es gibt ja zB. ZFS der für jeden Eintrag eine Checksum schreibt. Was genau macht der ECC wenn man ein eigenes Filesystem braucht um die Daten zu prüfen?
2.) Was macht der ECC der HDD?
Es gibt ja zB. ZFS der für jeden Eintrag eine Checksum schreibt. Was genau macht der ECC wenn man ein eigenes Filesystem braucht um die Daten zu prüfen?
Simple ECC Algorithmen können nur einen einzigen Bitfehler pro Sektor (512 Byte bzw. 4096 Byte) korrigieren und zwei Bitfehler sicher erkennen. Im Gegensatz zu SSDs verwenden Festplatten wohl heute noch relativ simple ECC Algorithmen. Somit kann ab 3 Bitfehlern pro Sektor ein Fehler ohne weitere Checksummen nicht mehr sicher erkannt werden. Die Checksummen der Dateisysteme prüfen zusätzlich auch den kompletten Weg über das Interface bis hin zum physikalischen Speicher.
Plus, "Festplatten-ECC" ist eine interne Angelegenheit. Da geht es nicht mehr um Inhalte, sondern nur, ob von 10bits auch tatsächlich 10bits richtig geschrieben wurden oder ob eins davon unterwegs umgekippt ist.
Ansonsten fürcht ich beantwortet der verlinkte Artikel nicht wirklich irgendetwas.
Kurz zusammengefaßt:
-Mit steigender Sektorengröße (in Verbindung mit Dateisystemen mehr oder weniger synonym mit Clustern => Dateisystemsektoren sind ggf größer als ein physikalischer Sektor, ergo 1 Dateisystemsektor = ein Cluster aus mehreren physikalischen, ggf aber auch nur einer)...
*** sinkt der Verwaltungsaufwand, da bei gleicher Gesamtgröße weniger Sektoren adressiert werden müssen
*** kann man der berüchtigten "2TB-Grenze" für MBR(vs GPT) entgegentreten, weil die keine "Größen-Grenze" ist, sondern in der Zahl der adressierbaren Sektoren begründet ist und mit größeren Sektoren paßt dort mehr rein
*** steigt der erwartete Clusterverschnitt (womit die erwartete Nutzlast wieder sinkt) im Dateisystem, da in einen Festplattensektor ebenso wie in ein Dateisystemsektor jeweils nur genau EIN Datum geschrieben werden kann, weshalb jede Datei MINDESTENS 1 Dateisystemsektor belegt, egal wie klein sie auch sein mag.
Größere Dateisystemsektoren beschleunigen daher den Zugriff auf große Dateien etwas, da weniger von diesen Dateisystemsektoren gelesen und geschrieben werden müssen. Besonders gut, wenn Verarbeitungsgrößen übereinstimmen, also zB 64kB am Stück von der Festplatte holen, 64kB am Stück im RAM ablegen,64kB am Stück an die CPU verfüttern, 64kB dort wieder abholen.... denke, es ist klar, wohin das geht.
Aber man erkauft sich das mit dem Verschnitt, weswegen das wirklich nur für große Dateien hilft.
Adressen spart man nur, wenn es 4kn Platten sind, bei den meisten HDDs wird aber trotz physiaklischer
4k Sektoren immer noch logisch 512 Byte pro Sektor emuliert (512e).
Krümelchen schrieb:
1.) Bringt mir es effektiv etwas wenn ich statt 4kB, 64kB verwende?
Das kannst Du nicht, Du kannst die Größe der physikalischen Sektoren nicht beeinflussen, die legt der Hersteller bei der Fertigung fest. Was Du meinst ist die Clustergröße, also die Größe der Cluster des Filesystems und da werden eben 1 oder mehrere Sektoren der Platte als ein Cluster und damit als kleinste Zuordnungseinheit verwendet. Dies ändert aber gar nicht an der Größe der physiaklischen Sektoren der Platte oder deren ECC.
Krümelchen schrieb:
2.) Was macht der ECC der HDD?
Es gibt ja zB. ZFS der für jeden Eintrag eine Checksum schreibt. Was genau macht der ECC wenn man ein eigenes Filesystem braucht um die Daten zu prüfen?
Das ist durchaus ähnlich, die HDDs bilden auch eine Prüfsumme und durch den verwenden Algorithmus ist es möglich Bitfehler bis zu einer bestimmten Anzahl (wie viele genau verraten die Hersteller nicht) zu korrigieren. Außerdem wird bei SATA die Übertragung über eine CRC32 (pro FIS, welches maximal 8192 Byte Nutzdaten übertragen kann) abgesichert und bei Fehlern wiederholt.
HDDs liefern auch keine falschen Daten, außer man fordert sie über entsprechende Befehle oder Konfigurationen dazu auf, sondern eben Lesefehler wenn die Daten nicht zur ECC passen (der Sektor wird dann als schwebender Sektor markiert). Ausnahmen sind Fehler auf den internen Datenpfaden, dagegen sind Enterprise HDDs abgesichert und auch Enterprise HBAs/RAID Controller haben immer ECC RAM als Cache, oder FW Bugs, die aber zum Glück selten vorkommen. Dann und nur dann hilft die Prüfsumme wie sie Filesysteme wie ZFS eben noch einmal auf Filesystemlevel anlegen.
Simpson474 schrieb:
Simple ECC Algorithmen können nur einen einzigen Bitfehler pro Sektor (512 Byte bzw. 4096 Byte) korrigieren
Du verwechselst das mit der ECC bei RAM, die ECC bei HDD kann durchaus auch mehr als einen Bitfehler korrigieren, denn Bitfehler sind bei HDDs (wie auch SSDs) durchaus nicht selten und daher gibt es eben eine ECC hinter jedem Sektor bzw. bei NANDs meist hinter jeder Page, wofür NAND übrigens ab Werk zusätzliche Bits für jede Page bereithält. Dies sind durchaus 5% und mehr der nominalen Kapazität die es noch mal extra pro Page gibt und die auch nicht zum Overprovisioning zählt, das OP kommt noch einmal extra oben drauf.
Nein, nicht 10 Bit, sondern ein physikalischer Sektor, also 512 opder 4096 Byte, die Platten schreiben immer einen physikalischen Sektor plus dessen ECC und wenn weniger als diese 512 oder 4096 überschreiben werden, dann muss die Platte die alten Daten erst lesen, tauscht dann die überschriebenen Daten aus, berechnet die neue ECC dafür und schreibt danach bei der nächsten Umdrehung erst den neuen Inhalt des Sektors mit der neuen ECC dahinter auf die Platte. Außer wenn der Sektor vorher als schwebender Sektor bekannt war, prüft sie die Daten auch danach nicht, die ECC wird immer nur beim Lesen geprüft, niemals beim Schreiben, da wird sie ja erzeugt.
Die sollte man korrekterweise immer als Cluster bezeichnen, denn auch wenn es früher mal so was das diese die Größe eines Sektors der Platte hatten, ist dies längst nicht mehr so. Was früher alles nur als Sektor bezeichnet wurde, wird heute unterschieden in physikalische Sektorgröße, logische Sektorgröße (wie viele Bytes werden pro LBA adressiert) und eben die Clustergröße (wie viele logische Sektoren werden vom Filesystem jeweils zu einem Cluster zusammengefasst).
RalphS schrieb:
Größere Dateisystemsektoren beschleunigen daher den Zugriff auf große Dateien etwas, da weniger von diesen Dateisystemsektoren gelesen und geschrieben werden müssen.
...
also zB 64kB am Stück von der Festplatte holen,
Nein, größere Cluster sind nur schneller, wenn es um Fragmentierung des Filesystems geht, denn ein Fragment eines Datei kann nie kleiner als ein Cluster sein. Die Adressierung der Platten erfolgen aber auf Basis von LBAs, die Platten selbst wissen von den Clustern ja auch gar nichts und die ATA Befehle erlauben es einen LBA und bis zu 2^16 darauf folgende LBAs mit einem Befehl zu adressieren, was jede vernünftige OS auch so macht und dies über die Grenzen der Cluster hinweg. Die Größe der Cluster ist also egal, wenn der Treiber es erlaubt z.B. 256k pro Befehl zu lesen, dann werden eben bei 4k pro Cluster 64 Cluster auf einmal gelesen und 64k Clustern eben 4 Cluster, sofern eben die nächsten 256k noch zum Fragment der Datei gehören und noch von der Anwendung angefordert wurden, also auch wirklich gelesen werden sollen. Man muss und möchte ja nicht immer die ganze Datei lesen, außer man hat ZFS, dann muss immer erst die ganze Datei gelesen werden damit das FIlesystem anhand seiner Prüfsumme auch feststellen kann ob die Daten korrekt gelesen wurden.
Bei Verwendung einer ECC muss eben immer so viel gelesen werden wie die Daten über die diese ECC gebildet wurde, was auf Ebene der HDD eben ein physikalischer Sektor, bei SSDs eine NAND Page (weniger kann man bei NAND sowieso nicht lesen) ist und bei ZFS oder btfs dann eben eine ganze Datei.
Ja, so in etwa hatte ich das auch gemeint und die 10b waren eher eine Hausnummer Richtung 8b/10b als in Richtung Festplatten-Fehlerkorrektur.
Re: (leichte) Beschleunigung in bezug auf Clustergröße, Du führst das ja recht gut aus, was ich in wenigen Worten andeutete. Weniger Cluster gleich geringere Chance auf Fragmentierung bei selber Dateigröße (nicht daß das bei SSDs wen interessieren würde), aber eben auch 1 Cluster lesen = 1 Cluster verarbeiten statt mehrere davon, wovon man allerdings nur dann profitiert, wenn man mit diesem Alignment auch weiterarbeiten kann. Bringt ja nichts, in einem Schritt 64kB vom Datenträger zu holen, wenn man die dann wieder in 4kB Seiten zerlegen, die dann einzeln verarbeiten und hinterher wieder in ein 64kB großes Segment zum Zurückschreiben zusammenbauen muß.
In jedem Fall sind wir uns glaub ich alle einig, daß größere Cluster insbesondere im Heimgebrauch, aber auch im normalen Soho-Betrieb nicht nur nichts bringen, sondern eher Platz verschenken. Ausnahmen sind ggf. Datenbankdaten bzw die Datenträger dafür.
PS. Wenn ich nicht wieder mal was verschlafen hab, schreibt ZFS Checksums blockweise, nicht dateiweise. Immerhin werden Dateien von ZFS intern noch fünfmal aufgemischt in Form von Dateisystemkopie, Mirror, Stripe, dann wird der Käse ggf noch komprimiert und/oder dedupliziert, da hat man überhaupt nichts davon, Dateien zu prüfsummen.
Die Checksums bei ZFS dienen denn auch der Selbstheilungsfunktion: Ich hab drei **logische*** Kopien einer Datei - egal in welcher Form die auch vorliegen mögen; komprimiert, dedupliziert, sonstwas, jedenfalls nicht bitidentisch --- und eine Kopie ist ungleich den beiden anderen, dann ist erstmal klar, daß was nicht stimmt. Ab hier wird dann blockweise geschaut, welche Checksums gültig sind und welche nicht und dann diejenigen Blöcke durch intakte Blöcke einer der (logischen) Kopien ersetzt. Wie groß die sind kann man auch bei ZFS selber festlegen.
Die 8b/10b Bitkodierung hat nichts mit einer Fehlererkennung oder -korrektur zu tun, sondern da geht es darum die Frequenz der seq. Übertragung zwischen Sender und Empfänger synchron zu halten, eben indem es garantiert auch Flanken im Signale gibt anhand deren der Empfänger seine Frequenz nachjustieren kann.
RalphS schrieb:
Weniger Cluster gleich geringere Chance auf Fragmentierung
Jein, natürlich sind insgesamt weniger Fragmente möglich, wenn ein bestimmte Platz in größere Teile aufgeteilt wird, aber vor allem bewirkt es eben auch das man selbst bei starker Fragmentierung mehr Daten am Stück lesen bzw. schreiben kann.
RalphS schrieb:
Bringt ja nichts, in einem Schritt 64kB vom Datenträger zu holen, wenn man die dann wieder in 4kB Seiten zerlegen, die dann einzeln verarbeiten und hinterher wieder in ein 64kB großes Segment zum Zurückschreiben zusammenbauen muß.
Warum sollte dies nötig sein? Normalerweise kann ein Rechner 64 k am Stück mit einem ATA Befehl lesen oder schreiben, sofern der Treiber nicht sehr limitiert ist und nur kleine Zugriffe erlaubt. Die Clustergröße spielt für die Länge der Zugriffe keine Rolle, es wird nicht clusterweise gelesen, sondern auch über die Grenzen von Clustern hinweg, sonst wären die seq. Zugriffe bei NTFS mit seinen üblicherweise 4k Clustern ja nicht so viel schneller als die 4k Zugriffe, denn bei denen kommen selbst die schnellsten SATA SSDs mit hoher QD nicht über 400MB/s, seq. sind aber über 500MB/s durchaus normal.
