Benji18 schrieb:
wir haben micron (crucial) SSDs und die sind der letzte Dreck, frimware Bugs on mass. wenn man vollmundig behauptet OPAL zu unterstützen und dann kannst du es nicht verwenden weil das Teil so verbuggz ist das ein Datenverlust Auftritt ja tolle SSD (im übrigen haben wir bereit 5 Updates für diese SSD ausgerollt...)
Da kann eigentlich nur die m500 sein, bei der gab es wirklich noch relativ viele FW Updates und der Queued Trim Bug wurde dort nie behoben.
Benji18 schrieb:
mal abgesehen davon das diese SSD zu haufen ausfallen und zwar spontan ohne Anzeichen!
Das ist bei SSDs typisch, die fallen meist ohne Vorankündigung aus, außer das NAND ist wirklich am Ende und dat kaputt, dann gibt es auch schon mal Fehlermeldungen die auf einen Ausfall hindeuten könnten, aber die NAND Hersteler wie Crucial, Micron und Samsung verbauen durchweg gute Qualitäten und die vertragen so viele P/E Zyklen, da dauert es bis man da ankommt und Heimanwender werden das wohl niemals erleben, da fällt vorher wohl was anderes aus wie eben der Controller (z.B. durch eine kalte Lötstelle) und das dann eben spontan.
andr_gin schrieb:
1.) Ja Samsung ist für den queued TRIM Bug verantwortlich. Das ist aber eine ganz andere Baustelle und hat mit dem Problem von Algolia absolut nichts zu tun. Das muss man separat betrachten.
Wie kann man nach der Niew und meinem Blick auf den Kernel Fix noch so einen Blödsinn behaupten?
Die Antwort des Kernelentwicklers ist doch auch klar und streitet den Bug auch nicht ab:
Es stand auch schon eindeutig im Blog:
andr_gin schrieb:
2.) Ich vermute einfach, dass der Fehler bei Intel SSDs grundsätzlich auch vorhanden war, jedoch durch einen anderen zeitlichen Ablauf nicht zum Tragen gekommen ist. Oder die Intel SSDs unterstützen ein Feature mehr oder weniger und wurden anders betrieben.
Der Fehler ist ja im Linux, nicht in der SSD, da wird im Kernel ein Pointer überschrieben, bzw. wohl die Daten auf die er zeigt und im Ergebnis werden die falschen LBAs getrimmt, da kann die SSDs im Prinzp nichts dafür, außer das natürlich die Rotinen entsprechend der gemeldeten Features der SSDs funktionieren und da gibt es interessante Unterschiede.
So sind die
Intel DC S3500,
DC S3600 und
DC S3700 z.B. nur SATA 3.0 und aber nicht mit der SATA 3.1 Revision 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 wie z.B. der 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 bzw. des Inhalts auf den er zeigt ausgelöst, wieso lässt Intel nur 4 blocks of LBA Range Entries pro Befehl zu? Damit sind mehr Befehle nötig, für die Performance ist das eigentlich schlechter, aber Intel kennt mdraids gut, die haben da sogar die Unterstützung für die Verwaltungsdaten ihrer Chipsatz-RAID eingebaut:
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 die Probleme und vor allem der Algoila Blog genau die Werbung die Intel braucht um seine Marktführerschaft im lukrativen Enterprise SSD Segment gegenüber dem Verfolger Samsung mit seinen 3D NANDs zu behaupten, denn Broken SSDs: Samsung Working SSDs: Intel, mehr kann sich deren Werbung doch nicht wünschen. 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.
Und wenn es so ist, wer will Intel überhaupt jemals nachweisen können, den Bug vorher gekannt und mit seinen SSDs absichtlich gemieden statt ihn behoben zu haben? Und selbst wenn das gelänge, es ist ja nicht Intel Aufgabe einen Bug im Linux Kernel zu fixen der die eigenen SSDs überhaupt nicht betrifft und wenn sie daraus Profit ziehen indem sie wissen wie ihre SSDs den Bug umgehen, dann wären sie ja auch irgendwie dumm den Bug zu fixen, oder? Die andere Angaben in Identify Device Data können ja auch andere Gründe haben, da hat man eben einfach das Bit 5 in Word 222 vergessen und der Controlller kann eben nur 4 blocks of LBA Range Entries pro Befehl verarbeiten und nicht 8, wie die von Micron und Samsung. Eine böse Absicht wird man doch niemals nachweisen können, außer es taucht eine interne Kommunikation von den Linux an die SSD Leute bei Intel auf, die genau darauf hinweist das die SSDs solche Angaben machen müssen um nicht vom Bug betroffen zu sein.
andr_gin schrieb:
Vielleicht war bei den Intel SSDs auch einfach ein anderer RAID Controller verbaut.
Es gibt um ein SW RAID, die SSDs haben keine RAID Controller verbaut, ein wenig Ahnung vom Thema zu haben würde helfen weniger Unsinn zu schreiben!
andr_gin schrieb:
Etwas Anderes ist, wenn eine gewisse Verfügbarkeit garantiert wird mit entsprechenden Strafzahlungen.
Dann sind aber auch die Umgebungs- und Nutzungsbedingungen genau einzuhalten, sonst gelte. auch die ganze Angaben zu den Ausfallraten nicht.
andr_gin schrieb:
Trotzdem steht hier natürlich der gute Ruf von Samsung auf dem Spiel und würde einen extremen Imageschaden nehmen, selbst wenn sie nicht daran Schuld sind.
Was muss eingentlich passieren damit auch Du es begreifst: Samsung ist nicht dafür verantwortlich, das ist ein Bug im Linux Kernel beim Zusammenspiel von md-raid und Trim, da muss man schauen wer das implementiert hat, der ist verantwortlich!
Natürlich hat Samsung da in den Linux reindebuggt um einen Imageschaden abzuwenden, die waren sich ja offenbar auch sicher, dass es in der FW keinen Bug gab. Man stelle sich vor das wäre unter Windows oder Apple OS passiert die nicht quelloffen sind und wo Samsung eben nicht mal eben selbst debuggen kann.
andr_gin schrieb:
Selbst jetzt haben sie einen extremen Imageschaden, da viele nur die erste News lesen.
Eben und wie viele von denen lesen jetzt nicht oder begreifen nicht, dass Samsung gar keine Fehler in der FW ud das alles nur an dem Bug im Linux Kernel liegt? Du bist ja auch einer davon.
