SATA Command Queuing = sinnlos???

[Matti]

Wenn ich jetzt keinen Denkfehler habe, ist Command Queuing doch ein ziemlich sinnloses Feature. Es soll ja die Performance verbessern, wenn mehrere Programme gleichzeitig versuchen, auf die Platte zuzugreifen. Aber ich bin der Meinung, daß schon der normale Cache diese Performance-Einbußen weitgehend verhindert.

Schreiben:
Programm 1 schreibt an Stelle X, Programm 2 an Stelle Y und Programm 1 wieder an Stelle X. Mit Cache sieht das so aus: Die Daten werden zuerst in den Cache geschrieben, und erst wenn so viel Daten im Cache sind, daß sich das Wegschreiben lohnt, wird der Lese-/Schreib-Kopf aktiv. Dabei kann die Firmware der HDD die Daten in der Reihenfolge schreiben, wie es für die Performance am günstigsten ist, egal an was für einem Interface die HDD hängt.

Lesen:
Beispiel wie oben, aber eben mit Lesen: Der Lese-/Schreib-Kopf fängt an der Stelle X an, Daten zu lesen. Es werden aber nicht nur so viele Daten gelesen, wie angefordert wurden, sondern immer so viel daß es sich auch lohnt, den Lese-/Schreib-Kopf überhaupt an diese Stelle zu bewegen. Also werden idR schon Daten in den Cache vorausgeladen. Dann geht der Lese-/Schreib-Kopf an die Stelle Y, und wenn der 3. Lese-Befehl kommt, muß sich der Lese-/Schreib-Kopf nicht mehr bewegen, weil die Daten von Stelle X schon im Cache sind.

[Coda]

Öh und wenn die Reihefolge "Innen - Außen - Mitte" kommt? Der Cache ist nicht halb so groß wie ein Platter X-D

Übrigens sollte der Festplatten-Cache ein reiner Lesecache sein. Alles andere wäre zu riskant.

[Matti]

Übrigens sollte der Festplatten-Cache ein reiner Lesecache sein. Alles andere wäre zu riskant.
Daß die Daten nicht ungeschrieben längere Zeit im Cache sein sollten, ist mir schon klar. Aber ein paar ms könnten sie doch schon drin sein ... das würde auf jeden Fall reichen, den Lese-/Schreib-Kopf optimal zu führen.

Öh und wenn die Reihefolge "Innen - Außen - Mitte" kommt? Der Cache ist nicht halb so groß wie ein Platter X-D
Stimmt, das wäre ein Problem ... aber nur beim Lesen.

[Coda]

Daß die Daten nicht ungeschrieben längere Zeit im Cache sein sollten, ist mir schon klar. Aber ein paar ms könnten sie doch schon drin sein ... das würde auf jeden Fall reichen, den Lese-/Schreib-Kopf optimal zu führen.Nein wirklich nicht. Bei einem Stromausfall ist das sonst tödlich.

Stimmt, das wäre ein Problem ... aber nur beim Lesen.Siehe oben.

[PatkIllA]

@Coda
mit Journaling im Filesystem sollte das doch nicht das Problem sein. Die grade geschriebenen Daten sind eh im Eimer, aber das Filesystem bleibt wenigstens heil und reisst sonst nichts mit.

[Coda]

AFAIK geht gerade das Journal davon aus, dass die Daten in der richtigen Reihenfolge geschrieben werden.

[PatkIllA]

Aber das Journal markiert doch die Schreibvörgänge erst als durchgeführt, wenn es das OK von der Platte bekommen hat, egal ob von NCQ umsortiert oder nicht.
Kann mir nicht vorstellen, dass die bei NCQ nicht an Journaling gedacht haben oder nicht.