Das betrifft sowieso nur Linux und auch nur neuere Kernels ab 3.12. Bei Queued TRIM darf es natürlich nicht passieren, dass ein TRIM Befehl auf einen LBA dann hinter einem Schreibbefehl auf diesen LBA ausgeführt wird, der eigentlich nach dem TRIM kommen sollte. Nur ist ein TRIM auf einen LBA der sofort wieder beschrieben wird ja sowieso komplett unsinnig, denn wenn ein LBA überschrieben wird, weiß der SSD Controller ja auch sofort, dass die alten Daten die dort vorher standen nicht mehr gültig sind, dass muss man ihm nicht eine halbe Sekunden vorher mitteilen, die Mitteilung (also der TRM Befehl) macht nur Sinn, wenn der Controller danach auch genug Zeit hat um die dadurch als ungültig marktierten Daten eben bei der nächsten GC oder Idle-GC eben nicht mehr kopieren zu müssen.
Deshalb und weil bei Enterpriseanwendungen i.d.R. wenig gelöscht sondern meist überschrieben wird, spielt TRIM für Enterprise SSDs auch praktisch keine Rolle. Die Performance hällt man dort durch genug OP hoch, was gerade bei der Verwendung von Consumer SSD die ab Werk wenig OP bieten, sehr, sehr wichtig ist. Aber weil Consumer SSDs gewöhnlich auch weder einen Schutz der internen Datenpfade vor Datenkorruption noch (ausreichend dimensionierte) Stützkondensatoren haben, empfiehlt sich deren Einsatz in produktiven Serversystemen sowieso nicht, wenn die Datenintigität wichtig ist. Die dort problemlos laufenden Intel SSDs der DC S3000er Reihen unterstützen nur SATA in der Revision 3.0, Queued TRIM wurde mit der Revision 3.1 verabschiedet.
