News Samsung-SSDs: Algolias „TRIM-Bug“ bisher nicht reproduzierbar

[Holt]

Genau das bedeutet es, unter Windows besteht überhaupt keine Gefahr! Backups sind aber trotzdem unerlässlich, da jede SSD wie auch jede HW, ja sogar jede Glühbirne, jederzeit mal spontan ausfallen kann und nicht nur HW-Ausfälle bedrohen die Daten.

 

[Marco^^]

Da nutzt man aber idR keine Enterprise SSD mit entsprechender Firmware

Mit der Firmware allein ist es auch nicht getan, RAID controller Treiber usw und mit Supermicro Boards kenne ich mich nicht so aus ...

Ein Beispiel ist hier iXSystems & FreeBSD, die schreiben sogar ihre eigenen Treiber für die RAID controller.
https://webnew.ixsystems.com/services/


ArchLinux hat einen guten Wiki-Eintrag über SSD's & Trim, unter Linux kann man schon mit hdparm die SSD auf Trim support überprüfen.

wiki.ArchLinux#Solid State Drives

dmesg (Laufwerkserkennung des Kernels)

Als Admin:

# hdparm -I /dev/sda | grep TRIM

sda, sdb, sdc usw


Ich habe :

sda /root IntelSSD120A (discard)
sdb /home M500 (discard)
sdc /backup M500 (noauto,discard)

Ich habe kein fstrim als cron job.

hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM

hdparm -I /dev/sdb | grep TRIM
* Data Set Management TRIM supported (limit 1 block)
* Deterministic read data after TRIM

 

[Hallo32]

Wird Windows 10 queued trim unterstützen?
Gibt es dazu schon Informationen von Microsoft?

 

[gabber113]

Samsung Enterprise SSDs haben sicher nicht die gleichen Speicherprobleme wie die Samsung EVO/PRO. Aber ein Firmware-Problem würde ich bei der Firma nicht ausschliessen. Vielleicht wurde ja aus versehen die Selbstzerstörung ausgelöst.

cheers

 

[ulx]

OT: Wenn TRIM bei einer ssd, die es unterstützt, nicht läuft, arbeitet der SATA controller meistens im falschen Modus. Er MUSS im ahci Modus laufen. Im IDE (legacy) gibts kein Ncq, kein TRIM usw...
Bei den meisten controllern gilt das auch, wenn sie im RAID Modus laufen...

Das ist der typische Laien fehler...

 

[anyone23]

OEr MUSS im ahci Modus laufen. Im IDE (legacy) gibts kein Ncq, kein TRIM usw...

OT: Natürlich funktioniert Trim im IDE-Modus.

 

[Holt]

ulx, das ist falsch, auch im IDE Modus funktioniert TRIM, wenn es nicht z.B. durch den Treiber blockiert wird und i.d.R. ist eben der Treiber der Grund warum TRIM nicht geht. Im RAID Modus geht TRIM bei AMD z.B. nicht, was aber an der Kennung des Controllers, der wird zumindest bei der AM3(+) im RAID Modus dem System als SCSI Controller gemeldet und dann schickt Windows keine TRIM Befehle, die schickt zumindest das Nicht-Server Windows nämlich nicht an SCSI/SAS oder RAID Controller. Bei Intel ist das anders, da sieht das Windows gar nichts vom RAID und bei neueren System werden sogar SSDs getrimmt die im RAID 0 arbeiten.

Das hat aber wohl alles nichts mit dem System von Algolias, die verwenden ja Linux.

 

[Sir Luckal0t]

Es gibt ein Update von heute. Samsung sagt, es liege nicht an Samsung, sondern am bösen Linux!!!

UPDATE July 17:
We have just finished a conference call with Samsung considering the failure analysis of this issue. Samsung engineering team has been able to successfully reproduce the issue with our latest provided binary.

Samsung had a concrete conclusion that the issue is not related to Samsung SSD or Algolia software but is related to the Linux kernel. Samsung has developed a kernel patch to resolve this issue and the official statement with details will be released tomorrow, July 18 on Linux community with the Linux patch guide. Our testing code is available on GitHub.

This has been an amazing ride, thank you everyone for joining, we have arrived to the destination.

 

[highks]

Samsung sagt, es liege nicht an Samsung, sondern am bösen Linux!!!

Wo hat Samsung denn was von "bösem Linux" gesagt?
Samsung hat ja offensichtlich einen Kernel Patch veröffentlicht, der das Problem löst - wenn sie damit einen Fehler in ihrer Firmware vertuschen wollten, dann würde das spätestens morgen auffliegen, weil bis dahin alle Linux Experten den Patch untersucht haben werden.

 

[Jesterfox]

Der Patch besteht vermutlich darin die Samsung Enterprise SSDs auch mit auf die Blacklist für Queued Trim zu setzen ;-)

 

[Sir Luckal0t]

Ich habe einfach mal frei interpretiert - schließlich sind nur Samsung SSDs betroffen gewesen - natürlich kann es auch am kuscheligen Tux liegen

 

[Holt]

Der Patch besteht vermutlich darin die Samsung Enterprise SSDs auch mit auf die Blacklist für Queued Trim zu setzen ;-)

Das wird man ja morgen sehen und dann wäre es eben eher ein FW Fehler, aber dann hätten sie wohl kaum so ein Statement gebracht, denn nachdem ja schon im ursprünglichen Blogeintrag auf die Blacklist verwiesen wurden, wäre das zu offensichtlich gelogen. Also wird der Patch vermutlich nicht darin bestehen die SSD auf die Blacklist zu setzen.

schließlich sind nur Samsung SSDs betroffen gewesen

Es wurden von denen ja auch nur SSD von Intel und Samsung genutzt, also gilt umgekehrt, dass nur de von Intel nicht betroffen waren. Über SSDs weitere Hersteller kann man ja nichts aussagen, wenn sie nicht verwendet wurden.

natürlich kann es auch am kuscheligen Tux liegen

Das ist gar nicht so unwahrscheinlich, die sind ja eben auch oft die Ersten die neue Features unterstützen und gehen damit ein höhres Risko ein auch mal Fehler bei der Implementierung zu machen. Richtige Enterprise Linux Versionen basieren daher ja auch meist auf deutlich längerem Code, bei dem man solche Fehler dann schon erkannt und beseitigt hat.

 

[MichaG]

Es gibt ein Update von heute. Samsung sagt, es liege nicht an Samsung, sondern am bösen Linux!!!

Konnte jemand inzwischen das "offizielle Statement" in der Linux-Community finden? Ich wüsste nicht einmal, wo ich da suchen soll

 

[Piktogramm]

https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005
gefunden via blog.fefe.de

Anscheinend:
Samsungs SSDs behaupten mit den neueren Firmwares, queued Trim bzw. NCQ kombiniert mit Trim beherrschen, tun es aber nicht bzw. funktioniert es mit potentiellem Datenverlust (YEAH!).
Samsungs Patch: Trim Blacklist des Kernels um Samsung SSDs erweitern

Samsung behauptet aber anscheinend: Linux ist schuld (... denn Linux versucht doch tatsächlich Features zu nutzen die wir als verfügbar deklarieren... Also wirklich so ein Mist!)


@MichaG: Gutes Timing
Suchen kann man da in den Mailingslists und Patchnotes des Kernels bzw. den div. Bugtrackern.
Offiziele Aussagen von der LinuxFundation gibt es meist nur selten und wenn etwas öffentlichkeitswirksam wenn Linus mal wieder seine Meinung deutlich formuliert.

 

[MichaG]

Danke! Aber der verlinkte Eintrag ist von Ende April?!

BTW: Algolia hatte ja behauptet, dass das Problem nichts mit Queued Trim zu tun hat. Die Probleme mit Queued Trim sind schon lange bekannt.

 

[Piktogramm]

Naja, die letzten Einträge sind recht frisch und queued Trim bezogende Beiträge, die Antworten vom Samsung Support wiedergeben finden sich zum Juni diesen Jahres:

Mark Rein (gimpsmart) wrote on 2015-06-15:
Here's an edited summary of the reply I got from the "please contact our firmware engineers at xxx@xxx" address; turns out there's no engineers there either, but at least we finally have a sane non-formletter reply which *for the first time* states that Samsung is aware of the issue and is working on a fix at the firmware level. Good news for everyone:

"We are just the SSD tech support. We are not the FW engineers. They are in Korea and have been aware of the issue since it first started being reported online.

The latest stable Linux Kernal 4.0.5 successfully blacklists the affected drive(s) from queued TRIM. Linux can still use Sequential TRIM, so you’re not losing out on anything.

We see that you are well aware that Marc Carino and Martin K. Petersen are in contact with Samsung on how to resolve the issue since it started.

All we can say to users at this moment is that Linux is the only operating system that has this issue with the Queued TRIM. Linux is open source and can be modified by anyone, as such we do not support the OS. We recommend updating to the new kernel, as we have seen that other users have done so and it alleviated their issue(s)."

Algolia hat ansonsten doch nur Aussagen von Samsung wiedergegeben, ohne selbst validiert zu haben woran es nun genau liegt. Also sollte man korrekt sagen: Samsung behauptet, es liegt nicht an queued Trim bzw. Trim in Verbindung mit NCQ, gleichzeitig wird aber ein Patch eingereicht, der die Samsung SSD über die bekannte Blacklist auf serielles Trim beschränkt. Das allein ist merkwürdig. Zudem gibt es in oben verlinktem Bugtracker Hinweise darauf, dass wenn die Samsung Technik befragt wird, andere Antworten veröffentlicht werden, solang Samsungs PR Abteilung da nicht davor geschalten ist.

Meine Vermutung daher:
Die Agolia Sache hat eine Welle gemacht, die nahezu jeden Linux Admin mit Verantwortlichkeiten im Bereich Storrage erreicht haben dürfte. Samsung hat also auf jeden Fall die Öffentlichkeitsabteilung eingeschalten und kein Techniker wird gegenüber Agolia eine Aussage getroffen haben, ohne, dass da eine Freigabe im Sinne der Firmenpolitik ein Abgleich mit dieser erfolgt wäre. Natürlich ohne Rücksicht auf den Wahrheitsgehalt der Aussagen. Denn Samsung droht hier ein enormer Gesichtsverlust. Als Hardwareanbieter für den professionellen Einsatz will man unter Admins nicht als Firma gelten, die Produkte auf den Markt werfen, die Funktionalitäten dem Betriebssystem gegenüber anbieten, die jedoch defekt sind und zu Datenverlust führen. Unter solchen Bedingungen landet man fix für ein paar Jahre auf der Blacklist der Beschaffung im Enterprise bereich, denn solche unberechenbaren Defizite der Verlässlichkeit will man in keiner Storagelösung. Vor allem da der Markt von Flash Lösungen für Server gerade sehr hart umkämpft ist, da tut jedes Prozent Marktanteil welches man an EMC, Intel, Micron & Co verliert richtig weh!
Für mich sieht das ganze so aus, als würde Samsung da gerade sehr hoch pokern.

Ab hier wilde Spekulation:
Mich würde auch nicht wundern, wenn Samsung sicher gestellt hat, dass Algolia nicht von der offiziellen Linie abweicht.

 

[MichaG]

Algolia hat ja schon vor dem Einschalten von Samsung behauptet, dass es nichts mit den bekannten Queued Trim Problemen zu tun habe.

A lot of discussions started pointing out that the issue is related to the newly introduced queued TRIM. This is not correct. The TRIM on our drives is un-queued and the issue we have found is not related to the latest changes in the Linux Kernel to disable this feature.

Trotzdem sollten die betroffenen Samsung-SSDs nicht nur in der Linux-Blacklist geführt werden, sondern auch ein Firmware-Update erhalten - ging bei Crucial (abgesehen von der M500) ja auch.

 

[Holt]

Piktogram schreib keinen Müll, die Samsun 8* wurde nicht von Samsung in die Blacklist eingetragen sondern wegen des Blogs von Algolia. Es geht um einen Kernel Patch den Samsung laut Blogeintrag vom 17.07. am 18.07. bringen wollte. Danach kann man vermutlich dann auch andere SSDs von der Blacklist werfen, denn die sagt ja nicht aus, dass deren FW zwangsläufig buggy ist, sondern nur das der Kernel Bug den Samsung offenbar gefunden hat bei denen auch zuschlägt und das kann an der Kombination von Flag in deren identify device data liegen, aufgrund denen das OS erkenen kann, was die SSD (und HDDs) denn für Features unterstützen. Dazu wurden die Spezifikationen von T13 in der Entwurfsphase öfter geändert und so banal wie viele sich das wohl vorstellen, ist es ganze eben nicht und schon gar nicht unter Linux welches auch noch verschiedene I/O Schedulers besitzt in denen die Reihenfolge von Requests auch noch ungestelt werden können. Gelangt ein TRIM Befehl hinter den eigentlich nachfolgenden Schreibbefehl für die gleiche Adresse ist der Datenverlust vorprogrammiert und liegt eben nicht an der FW der SSD, die hat dann ja getan was sie sollte, erst geschrieben und dann getrimmt.

Vielleicht hat Intel in der FW seiner SSDs einfach die TRIM Befehle die sich auf gerade beschriebene LBAs beziehen einfach nur ignoriert um den Fehler im Linux Kernel zu umgehen, denn es macht eigentlich überhaupt keinen Sinn sofort nach dem Schreiben wieder zu Trimmen so wie es keinen Sinn macht nach dem TRIM auf eine Adresse diese sofort wieder zu beschrieben, denn durch das Beschreiben erfährt der Controller der SSD ja auch, dass die alten Daten dir vorher für diese Adressen im NAND abgelegt waren, nun ungültig sind. TRIM macht nur wirklich Sinn, wenn dazwischen Zeit für die Idle-GC bleibt oder wenigstens danach ganz andere Adressen be- oder überschrieben werden.

 

[Jesterfox]

Die 8x0 Samsungs waren doch schon vor dem Vorfall auf der Liste? Algolia hatte aber auch gar keine solchen im Einsatz sondern Enterprise-SSDs mit anderem Namen in der Firmware.

 

[Holt]

Algolia hatte neben den Enterprise SSDs von Samsung auch 840 Pro und 850 Pro im Einsatz, von Intel dagegen nur Enteprise SSDs. Das steht aber auch im Blog und sich ein wenig in das Thema einzulesen bevor man es kommentiert, hat noch nie geschadet:

Broken SSDs: (Drives on which we have detected the issue)

SAMSUNG MZ7WD480HCGM-00003
SAMSUNG MZ7GE480HMHP-00003
SAMSUNG MZ7GE240HMGR-00003
Samsung SSD 840 PRO Series
recently blacklisted for 8-series blacklist
Samsung SSD 850 PRO 512GB
recently blacklisted as 850 Pro and later in 8-series blacklist

Working SSDs: (Drives on which we have NOT detected the issue)

Intel S3500
Intel S3700
Intel S3710

Laut dem englischen Wikipedia war der Blogeintrag von Algolia der Grund für die Ausnahme der Samsung 8* in die Blacklist:

TRIM commands have been linked to serious data corruption in several devices, most notably Samsung 8* series.[18] The data corruption has been confirmed for the Linux operating system on these devices as of July 1, 2015[19]
...
References
...
18 ^ When Solid State Drives are not that solid

Es reichen bei Linux eben schon Gerüchte ohne jeden Beweis für eine Verurteilung und die Aufnahme in die Blacklist.