Blockgröße bei Flashdrives, Auswirkung auf Performance und Lebensdauer?

[1ST1]

Drüben ist gerade eine interessante Diskussion im Gange: http://www.apollo-core.com/knowledge.php?b=2&note=12012&z=CUKaU9

Es geht um die Blockgröße bei CF-Karten, SD-Karten usw. und wie der Amiga Schreibzugriffe durchführt. Interessant wäre zu wissen, ob der ST das auch so macht. Das könnte nämlich Auswirkungen auf die Performance und Lebensdauer Flash basierter Laufwerke haben!

Die Blockgröße bei Flash-Laufwerken beträgt nämlich 4 oder 8 kB (es gibt bei älteren Flash-Speichern sicher auch Abweichungen nach unten. Die jeweils aktuelle Blockgröße kann man aber beim Laufwerk erfragen). Zumindestens der Amiga schreibt aber auf unterer Ebene immer Blöcke von 512 Bytes. Die Frage ist, wie groß ist bei gängigen Plattentreibern am ST diese Blockgröße, die direkt übers Kabel übertragen wird? (Also keine höheren Softwarelayer, sondern direkt die Kommuniukation mit dem Laufwerk)

Wenn es so wie beim Amiga wäre, dass der Atari-Plattentreiber immer 512 Byte Häppchen an das Laufwerk schickt, würde das nämlich bedeuten, dass wenn größere Datenmengen geschrieben würden, dass das Flashlaufewerk dann für jedes 512 Byte Häppchen einen 4 oder 8 kB großen internen Block aus den Speicherzellen auslesen würde, die 512 Bytes da an die richtige Stelle reinkopiert, und das Ganze wieder weg schreibt. Und das für jeden 512er Block einzeln. Das heißt, beim Schreiben von 4 KB würde der Flash-Block acht mal eingelesen, um 512 Bytes aktualisiert und wieder weggeschrieben. Das heißt, ein Vorgang der im Flashlaufwerk in einem Rutsch passieren könnte, wenn man dem Laufwerk von vorneherein einen 4 KB Block (oder 8 KB bei entsprechenden Flashs) schicken würde, würde dieser in einem Rutsch geschrieben werden können.

Das würde zum einen noch etwas Performance bringen, und es würde zum anderen jede Menge Schreibzugriffe auf die Speicherzellen ersparen, was deren Lebensdauer erhöhen würde. Im Amiga-Lager könnte das jetzt dazu führen, dass die ihre Device-Treiber dafür optimieren. Wäre das Atari-seitig auch nötig/sinnvoll, oder wurde das, z.B. in HDDRIVEr schon gemacht?

[Arthur]

Ich vermute mal dass das Flashmedium das komplett selbst organisiert... nach außen hin verhalten sie sich ja wie eine Festplatte und auch uralte Atari HDD-Treiber funktionieren damit.

[1ST1]

Ja, die tut nach Außen so als hätte sie 512 Byte Sektoren, aber intern verwendet sie 4  oder 8 KB Blöcke. Und dann bedeutet jedes Schreiben von 4 KB dass der ganze Block 8x komplett neu beschrieben wird. Wenn das Flashmedium aber von vorneherein weiß, da kommen jetzt in einem Rutsch 4 oder 8 kB, dann wird das auch in einem Rutsch gemacht und belastet die Speicherzellen deutlich weniger.

[ari.tao]

Im HDDRUTIL 8.45 stehen als Defaults für die beiden Caches je 8 Sektoren, vielleicht nicht ohne Grund. Am besten US fragen.

[mfro]

Die Caches sind da zweitrangig (die kann man sowieso nur als "Lesebeschleuniger" verwenden.

GEMDOS schreibt immer clusterweise. Rwabs() ist die BIOS-Funktion, die das Lesen und Schreiben erledigt, die wird mit Startsektor, Anzahl Sektoren als Parameter aufgerufen.

Falls jetzt nicht ein ganz schwachsinniger Plattentreiber darunter das in Einzelsektor-Writes runterbricht (mir wäre keiner bekannt, der das täte), schreibt der HD-Treiber auch clusterweise auf das Medium.

Wenn also die Clustergrösse gross genug ist (bei der Mediengrösse heutzutage dürfte das meist der Fall sein), werden die Flash-Sektoren im schlimmsten Fall (bei ungeschickter Partitionierung) doppelt so oft beschrieben als unbedingt notwendig.

Kritisch sehe ich da eher die FAT-Sektoren - auf denen wird praktisch ständig rumgejuckelt - aber das ist eben eine FAT-Krankheit.

[ari.tao]

... schreibt der HD-Treiber auch clusterweise auf das Medium.
Wenn also die Clustergrösse gross genug ist ( ... ), werden die Flash-Sektoren im schlimmsten Fall (bei ungeschickter Partitionierung) doppelt so oft beschrieben als unbedingt notwendig.

Das heißt also: Für heutige Flash-Medien wäre eine Clustergröße von 8kB optimal?
Genau die richtet der HDDRIVER für FAT16-Parts. der Größe 255,9MB ein.

[Thorsten Otto]

[Das heißt also: Für heutige Flash-Medien wäre eine Clustergröße von 8kB optimal?
Genau die richtet der HDDRIVER für FAT16-Parts. der Größe 255,9MB ein.

Kommt drauf an wie die eingerichtet werden. 8K Clustergösse kann zb. ein logischer Sektor von 8k, oder 16 logische Sektoren a 512B sein. Im letzteren Fall (was der Treiber vermutlich nimmt, wenn das Interface nach aussen eine Sektorgrösse von 512B meldet), bringt das vermutlich wenig, weil dann immer noch in kleinen Häppchen gelesen/geschrieben wird.

[czietz]

EmuTOS und sicherlich auch HDDRIVER nutzen doch bei IDE den Multiple Mode, d.h. wenn ein Schreibzugriff z.B. für  16 Sektoren kommt, dann werden die alle in einem Transfer geschrieben.

[mfro]

Das heißt also: Für heutige Flash-Medien wäre eine Clustergröße von 8kB optimal?
Genau die richtet der HDDRIVER für FAT16-Parts. der Größe 255,9MB ein.

Oder eben ein Vielfaches davon. Wenn dann noch die Clustergrenzen mit den Flash-Sektorgrenzen zusammenfielen (ich wüsste allerdings nicht, wie man das mit Bordmitteln sicherstellen könnte), wär's optimal.