Vielleicht führen die SSDs gar kein TRIM aus? Oder unterlassen TRIM wenn viel I/O stattfindet, dann ist das TRIM ja sowieso meist sinnlos. Es wird auch einen Grund haben, warum es bei Win 8 nun einen Offline TRIM in Form der Optimeirung von SSDs gibt, der genau wie fstrim bei Linux arbeitet. Das wäre bei Windows eigentlich komplett unnötig, weil auch immer Online, also sofort nach dem Löschen von Dateien und beim Formatieren getrimmt wird, da dürfte ja kein als unbelegt erkannter Cluster auch ungetrimmt geblieben sein und vom Offline TRIM wäre kein Vorteil zu erwarten. Win 7 hatte das ja noch nicht, wozu hat MS dann eingebaut?
Schon von Trimcheck habe ich ein eigenes Tool dafür geschrieben und bei einigen SSDs auch komischer Verhalten festgestellt, die haben auch nicht alle LBAs getrimmt denn mein Tool hatte alle getrimmten LBAs überprüft. Da vermute ich, dass es Situationen gibt, in denen die SSD Controller TRIM Befehl einfach mal nicht ausführen, dann wären u.U. vielleicht schon die Intel deswegen nicht betroffen.
Außerdem sind die
Intel DC S3500,
DC S3600 und
DC S3700 nur SATA 3.0 und nicht 3.1 konform, aber die haben laut Datenblatt 0x101F im Word 222 der Identify Device Data und die unteren Bit bedeuten:
6: Supports SATA Rev 3.1
5: Supports SATA Rev 3.0
4: Supports SATA Rev 2.6
3: Supports SATA Rev 2.5
2: Supports SATA II: Extensions
1: Supports SATA 1.0a
0: Supports ATA8-APT ATA8-AST
Intel setzt nur die Bits 0,1,2,3 und 4, nicht einmal Bit 5 welches den Support der SATA 3.0 Norm kennzeichnet, die werden als von Linux nicht wie SATA 3.0 SSDs mit den Features der 3.0er Revision behandelt, auch wenn die physikalisch natürlich diese Geschwindigkeit haben und erreichen.
Also warum hat Intel das macht? Die Datenblatter sagen klar "- SATA Revision 3.0; compatible with SATA 6Gb/s, 3Gb/s and 1.5Gb/s interface rates", wieso geben die Controller aber das Bit 5 beim Wird 222 mit dem sie das auch dem OS mitteilen dann nicht als 1 aus? Das ist
bei den Nachfolgern DC S3710 nicht anders. Warum gibt die SSDs sich selbst nicht als SATA 3.0 konform zu erkennen?
Dann hat bei denen Intel das Word 105 "Maximum number of 512-byte blocks of LBA Range Entries per DATA SET MANAGEMENT command" nur den Wert 4, bei
Microns M500 dagegen den Wert 8.
Leider gibt es bei Samsung keinen so guten Zugang zu den Datenblättern, aber ich haben eines für die SM843T und demnach sind da die dentify Device Data Word 222: 0x107F, also auch bis 5 und 6 gesetzt für Supports SATA Rev 3.0 und Supports SATA Rev 3.1 und Word 105 ist 8. Der Bug wird durch das Überschreiben eines Pointers ausgelöst, wieso lässt Intel nur 4 blocks of LBA Range Entries pro Befehl zu, womit mehr Befehle nötig sind? Intel kennt mdraids gut, die haben da sogar die Unterstützung für die Verwaltungsdaten ihrer Chipsatz-RAID eingebaut, man kann also ein Windows Intel Chipsatz RAID mit mdraid unter Linux mounten.
Wenn jetzt Intel den Bug kannte und statt ihn zu beheben die Werte der Identify Device Data seiner SSD so gewählt hat, dass er bei ihren SSDs nicht ausgelöst wird? Dann wäre der Blog genau die Werbung die Intel braucht um seine Marktführerschaft im lukrativen Enterprise SSD Segment zu behaupten, denn Broken SSDs: Samsung Working SSDs: Intel, mehr kann sich deren Werbung doch nicht wünschen und wenn es darum geht die eigene Marktstellung zu behaupten und zu stärken, ist für Intel auch noch nie ein Trick zu schmutzig gewesen, frag mal AMD. Außerdem wäre auch ohne den Blog den Leute aufgefallen, dass die Intel SSDs in diesen konfigurationen mit TRIM und mdraid problemloser laufen, sie also besser zu sein scheinen und wer will Intel jemals nachweisen, ob die den Bug kannten? Und selbst wenn, ist es ja nicht ihre Aufgaben einen Bug im Linux Kernel zu fixen und wenn sie daraus Prpfit ziehen indem sie wissen wie ihre SSDs den Bug umgehen, dann wären sie ja auch dumm den zu fixen.
