Die Diskussion geht bischen ins Leere, da für Trim-Support der Controller völlig egal ist.
_Jedem_ ATA-Controller kann man sagen, dass er ATA-Kommando X mit bestimmten Parametern an eine angeschlossene Platte schicken soll. Trim ist kein Wunderwerk sondern auch nur so ein ATA-Kommando wie "Sektor lesen", "Sektor schreiben" usw. (naja, fast: das Kommando heißt in Wirklichkeit "Data Set Management" und kann in einem Rutsch einen Block zusammenhängender Sektoren bearbeiten)
Wenn die Platte Trim kennt, hat man 2 Möglichkeiten es zu nutzen:
1. manuell: Man schaut sich sein Filesystem offline an, ermittelt unbenutzte Blöcke, erstellt eine Liste daraus, schickt mit einem Tool wie hdparm der Platte die Trim-Kommandos. Diesen Mechanismus könnte man z.B. aller paar Tage mal anwerfen, wenn man ein OS verwendet, was Trim nicht kann.
2. automatisch: Das Betriebssystem, bzw. sein Filesystem, muß im laufenden Betrieb die Info rausrücken, daß Blöcke auf der Platte frei geworden sind. Diese Info wird an den Plattentreiber weitergereicht, der daraus für die betroffenen Sektoren die nötigen Trim-Kommandos generiert und an die Platte schickt.
Damit die 2. Variante funktionieren kann, müssen a) das Filesystem b) der Plattencontrollertreiber und c) die Platte selbst mit Trim umgehen können. Der Controller ist egal. Es ist auch egal, ob der Controller IDE, AHCI oder was proprietäres spricht. Rohe ATA-Kommandos zur Platte schicken kann er in allen Modi und mehr ist nicht nötig. Wenn man den Controller-Modus umstellt (AHCI. IDE, whatever) kommt notwendigerweise ein anderer Treiber zum Einsatz, der ggf. b) nicht erfüllt. Deshalb ist über den Umweg des Treibers der Betriebsmodus des Controllers in der Praxis für automatisches Trim doch wichtig. Da aber jeder(?) SATA-Controller entweder AHCI oder IDE kann und die beiden dafür in Win7 enthaltenen Treiber mit Trim umgehen können, sollte es immer einen funktionierenden Modus geben.
