hddriver und ssds

[ragnar76]

Hallo,

als allererstes. ich benutze noch eine alte Version (6) die ich damals mit dem Linkadapter gekauft hab (Ich hoffe es wird mir, vorerst verziehen ) aber bevor ich ein Neukauf mache würde ich gerne wissen was passiert wenn ich eine SSD anschließe. Aktuell sieht es ja so aus das das man kaum noch neue P-ATA Platten bekommt. Daher habe ich schon (in meinem Falcon) ein ide auf s-ata adapter dran was wunderbar funktioniert. Nun habe ich mir für mein Laptop eine neue SSD gekauft und die alte würde dann in den Falken wandern. Was mich allerdings im Moment interessiert, unterstützt hddriver das benötigte TRIM Kommado (http://de.wikipedia.org/wiki/TRIM)?

Gruß
Bernd

[uweseimet]

Hallo,

HDDRIVER unterstützt TRIM nicht, aber selbst wenn dem so wäre, würde das nicht genügen. Denn nur das Betriebssystem (genauer: der Treiber für das Dateisystem) weiß, wann Blöcke freigegeben werden und wann TRIM eingesetzt werden kann. Da aber TOS TRIM beim Freigeben von Blöcken (Clustern) nicht unterstützt, kann der Atari mit TRIM nichts anfangen.
Nicht alle SSDs benötigen übrigens TRIM, manche neuere Modelle kommen auch ohne aus. Vermutlich ist der Datendurchsatz beim Schreiben ohne und mit TRIM beim Atari derselbe, da der Atari die Daten ohnehin deutlich langsamer überträgt, als die SSD sie verarbeiten könnte.

Grüße

Uwe

[uweseimet]

Hallo,

inzwischen habe ich erfolgreich eine Samsung 830 SSD (SATA-3) am SCSI-Bus des TT betrieben. Der Anschluss erfolgte mit einer Acard AEC-7720U SCSI-nach-IDE-Bridge, ergänzt um einen IDE-nach-SATA-Adapter. Eine etwas exotische Kombination, aber immerhin lassen sich so mit der AEC-7720U nicht nur IDE-Platten sondern auch diverse SATA-Geräte am TT betreiben. Auch ein SATA DVD-Laufwerk ließ sich so am TT verwenden.
In der Regel gibt es für diese Geräte, z. B. DVD/BD/DVD-RAM-Laufwerke, keine oder keine erschwinglichen SCSI-Ausführungen. Eine "echte" SCSI-nach-SATA-Bridge sollte natürlich erst recht funktionieren.
Von der SSD ließ sich HDDRIVER 9 übrigens problemlos booten.

Grüße

Uwe

[uweseimet]

Ergänzung: Auch eine Samsung 850 PRO funktioniert erwartungsgemäß mit demselben Hardware-Setup.

[franklukas]

Sehr interessant sind die Produkte aus Japan über Ebay (artmix) z.B. (SCSI auf Sata) 261701582493 und (SCSI auf CF) 301443480519 sowie (SCSI auf 2,5 Zoll SSD) 301443193379 ...

Ich hatte so einen SCSI auf CF Adapter am Atari TT, sehr schönes Stück Hardware.

[Arne]

HDDRIVER unterstützt TRIM nicht, aber selbst wenn dem so wäre, würde das nicht genügen. Denn nur das Betriebssystem (genauer: der Treiber für das Dateisystem) weiß, wann Blöcke freigegeben werden und wann TRIM eingesetzt werden kann.

Zum Verständnis muß ich hier mal nachfragen.
Die Begrifflichkeiten sind bei Flash-Speichern je nach Hersteller unterschiedlich, daher setze ich für meine Frage folgende Begriffe fest:
Sektor = Sektor des Filesystems i.d.R. 512Byte
Block = kleinste löschbare Einheit auf dem Flash-Speicher (z.B. 64KB)
Da nur TOS mit FAT arbeitet und der darunterliegende HD-Treiber nur Sektoren sieht (die mittels Rwabs() beschrieben/gelesen werden), kann der HD-Treiber nicht wissen welche Sektoren innerhalb eines Block (nach obiger Festlegung wären das z.B. 128 Sektoren je Block) von TOS bzw. dem Filesystem benutzt werden. Daher kann der HD-Treiber hier nicht TRIMmen. Ist das so korrekt?
Falls ja: könnte dann hier nur ein Tool helfen, das wie ein DefragPrg. über das FS (d.h. FAT) Bescheid weiß?
Müssen dann TRIM Befehle für jeden Block einzeln gesendet werden?

[uweseimet]

Unabhängig von Blöcken weiß der Treiber generell nichts über die Nutzung von Sektoren/Clustern, die in der FAT verwaltet werden. Er weiß auch nicht, wie die Daten in einer FAT zu interpretieren sind. Das weiß alleine das Dateisystem.

Durch eine Auswertung der FAT mit einem Tool sollte es möglich sein, die Blöcke zu bestimmen, auf die es ankommt. Wie genau die TRIM-Befehle aussehen müssten weiß ich nicht. Da HDDRIVER TRIM ohnehin nicht nutzen kann, habe ich mich nicht weiter damit beschäftigt.
Ein geeignetes Tool müsste sich auch selber darum kümmern, die TRIM-Kommandos low-level an das Gerät zu übertragen. Geht man davon aus, dass es sich bei den in Frage kommenden Geräten um IDE/SATA-Massenspeicher handelt, ist das per SCSI-Treiber nicht möglich. Die erforderlichen Kommandos werden auch von den aktuellen SCSI-Spezifikationen (insbesondere SBC-5) nicht abgedeckt. Eine Emulation für IDE/SATA-Geräte, wie sie HDDRIVERs SCSI-Treiber für diverse SCSI-Kommandos unterstützt, kommt für TRIM daher selbst theoretisch nicht in Betracht.
Und noch ein Punkt: Das Tool müsste sich entweder bei jedem Durchlauf merken,für welche weiterhin ungenutzten Blöcke TRIM bereits ausgeführt wurde, oder es müsste bei jedem Durchlauf unnötigerweise auch für diese Blöcke wieder TRIM ausführen.

[Arne]

Danke, dann ist mir die TRIM-Problematik wohl jetzt klar.
Mir ging es lediglich um SATA SSDs, da man diese inzwischen nachgeworfen bekommt (10,-€ für 128GB).

[uweseimet]

Der Vollständigkeit halber: Entgegen meiner ursprünglichen Annahme gibt es ein Pendant zu SATA-TRIM auch bei SCSI. Das nennt sich UNMAP, ist seit SBC-3 (2013) spezifiziert und auch im SBC-5-Draft (2023) noch drin. Wie gut sich TRIM und UNMAP aufeinander abbilden lassen habe ich nicht untersucht. Falls beide Kommandos ausreichend ähnlich sind ist grundsätzlich ein SCSI-Treiber denkbar, der TRIM für SATA-Platten auf der Basis von UNMAP emuliert. Ein geeignetes Tool, das diese Funktionalität nutzt, wäre aber weiterhin erforderlich.

[uweseimet]

Beim regelmäßigen Durchsehen und Aufräumen des Forums bin ich auf diesen Thread gestoßen und möchte eine Anmerkung zu SSDs ergänzen, die auch Speicherkarten betrifft.

Obwohl SSDs und Speicherkarten in der Regel nach außen hin 512 physikalische Bytes pro Sektor melden, werden intern meist größere Datenblöcke (4096 Bytes) gelesen und geschrieben. Daher ist es günstig, wenn eine Partition eine logische Sektorgröße von mindestens 4096 Bytes aufweist (also eine Kapazität von mindestens 128 MiB hat) und auf einem geeigneten Sektor beginnt. Dann passen die Partitionsparameter optimal zu den Eigenschaften des Mediums.
Dies hat zwei Vorteile: Bessere Performance und geringerer Medienverschleiß. Performance-Unterschiede dürften beim Atari kaum messbar sein, außer vielleicht bei den sehr hohen IDE-Übertragungsraten mit HDDRIVER im Fast-RAM und Falcon-Beschleunigern. Der Verschleiß spielt aber auf jeden Fall eine Rolle: Passt der Start eines logischen Sektors nicht zum internen Sektor-Layout, müssen pro logischem Sektor gleich zwei interne Sektoren gelesen/geschrieben werden. Unnötige Schreibvorgänge wirken sich aber negativ auf die Lebensdauer eines Mediums aus. Bei FAT-Dateisystemen werden insbesondere FAT-Sektoren besonders häufig geschrieben.

HDDRUTIL ab Version 13 berücksichtigt dies automatisch beim Partitionieren mit einem GPT-Schema. Hier werden die Partitionsgrenzen möglichst so gewählt, dass der Verschleiß minimal und die Performance (mit dem Atari zumindest theoretisch) optimal ist. Wenn man ein solches Medium zum Datenaustausch mit anderen Plattformen nutzt, kommt auch der Performance-Vorteil auf jeden Fall zum Tragen.