News Algolia vs. Samsung: Linux-Patch gegen TRIM-Bug mit Samsung-SSDs

[DaBzzz]

Mir ist völlig egal wer Schuld war. Ich hab Seit 6 Jahren nur Crucial SSDs in Betrieb, musste noch nie irgend etwas patchen, alles läuft wie geschmiert unter Win sowie unter Linux. Samsung, die gefühlt in den letzten Jahren 78 Patches veröffentlicht haben für ihre Produkte kaufe ich mir höchstens wenns nix anderes mehr gibt.

Ah, tatsächlich? Nie eine m4 (prä-0309) gehabt, die sich nach 5184h pünktlich jede Stunde verabschiedet und nen BSOD herbeizaubert?

Bei mir sind drei Samsungs im Einsatz, ne 830, ne später gekaufte 470 und ne 840 Evo, alle ungepatcht. Und der goldene Kernschrott schlechthin, eine 40GB Vertex 2. Obendrein laufen die 830/840 auch noch unter Linux und die Vertex unter Solaris - alle problemlos. Vielleicht PEBKAC?

 

[Holt]

Linux selber ist nicht das Prob!
http://blog.fefe.de/?ts=ab522174

Steht da war über mdraid? Der Fehler tritt bei mdraid im Zusammenhang mit TRIM auf! Ohne zu wissen ob die betroffenen SSDs im RAID laufen, sind also die ganze Informationen in den Linux Mailing Lists über Probleme nichts wert, gar nichts! Über Queued TRIM steht doch schon schon von im ersten Update im Blog:

UPDATE June 16:
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

Den letzlich Schuldigen hatte sie auch schon auf der Liste der Verdächten:

Mdraid – Is there a bug in mdadm? Did we use an improper configuration?

Da Holt hier mitlesen wird: Maeh, du hattest recht.

Alles klar, gut das zu hören. Fehler und Fehleinschätzungen passieren und man muss die auch zugeben können, dann lernt man auch daraus.

Selbst wenn der Bug im Linuxkernel drin waere, er ist opensource und der Treiber darin sollte zumindest von Samsung kommen, wenn nicht, dann sind sie daran auch schuld.

Wieso sollte der Treiber für eine SATA SSD von Samsung kommen? SATA SSDs brauchen und haben keine Treiber, die haben nur die SATA Host Controller und da gibt es bei Windows einmal den Microsoft, also den PCIIDE für den IDE Modus und dann den MSAHCI und seid Win 8 STORAHCI und alternativ die von den Herstellern der SATA Host Controller, die können auch in den Chipsätzen stecken, also von AMD, ASMedia, Intel, Marvell, NVidia etc.

Es gibt für SATA SSDs definitiv keine Treiber von den Herstellern der SSDs, oder kennt Du einen Treiber von z.B. Crucial, Kingston, OCZ, Plextor, Samsung, Toshiba oder Transcend für ihre SATA SSDs? Da gibt es wenn, dann diese meist unsinigen SSD Toolboxen und wenn es SSD Treiber gibt, dann nur für Modelle mit PCIe SSDs mit RAID Controllern drauf.

Egal wie mans dreht und wendet Samsung ist schuld.

NEIN, egal wie man es dreht und wendet, Samsung ist da komplett unschuld, wegen erwiesener Unschuld freigesprochen, das Basher wie Dich aber nicht abhalten wird sie dafür trotzdem weiter zu bashen, auch weil sie eben keine Ahnung von dem ganzen Thema haben, dafür aber umso mehr Meinung kundtun. Du weißt ja nicht einmal, dass SATA SSD keine Treiber haben und brauchen.

dann ploetzlich sei der Kernel schuld, wer auch immer dieser Herr Kernel ist.

Und Du weißt offenbar auch nicht einmal was ein Kernel ist, noch trauriger.

Ein Fehler, der nicht unbedeutende Schäden verursacht hat. Sowohl bei Algolia als auch bei Samsung.

Welchen Schaden hat denn Algolia genommen? Die sind doch dadurch erst viele Leute bekannt geworden, so wie Backblaze über seinen Blog und die Veröffentlich der Ausfallraten ihrer HDDs wohl mehr Leuten als durch ihre Werbung bekannt geworden ist.

Bleibt am Ende die Frage der Schuld also offen?

Nein, Schuld ist ein Bug im Linux Kernel, wer den zu verantworten hat, müsste man in den ganze Chancelogs nachsehen, aber da gilt am Ende dann vermutlich nur: "Shit happens"

Einfach nur peinlich, was samsung immer für einen unfertigen Mist auf den Markt wirft.

Nein peinlich ist nur VollgasPilot der unfertigen Mist ins Forum wirft. Samsung hat keinen Fehler gemacht, die haben einen bei Linux aufgedeckt der letztlich dazu geführt hätte, dass alle SSDs die dem System ähnliche Fähigkeiten melden auf der Blacklist gelandet werden. Da Samsung rund 50% Marktanteil bei SSDs hat, war die Wahrscheinlich früh betroffen zu sein eben auch besonders hoch.

Wenn der Fehler weder in der Algolia-Software noch an der Samsung-SSD sondern im Linuxkernel zu finden war, sollten doch SSDs anderer Hersteller in derselben Konstellation ebenso betroffen sein. Warum ist das nicht der Fall?

Einfach weil die SSDs andere Identify Device Data haben und die Betriebssystem diese entsprechend den Angaben oder auch anders ansprechen. Da steht extrem viel darüber drin, was eine Platte unterstützt, z.B. welche Version des SATA Sandards, welche Feature, wie viele Befehle gleichzeitig ausstehen dürfen (die QueueDepth), über wie viele LBAs ein Zugriffe maximal gehen darf und eben auch wie viele "512-byte blocks of LBA Range Entries per DATA SET MANAGEMENT command" erlaubt sind, bei den Intel nur 4, bei Micron und Samsung 8. Entsprechend größer muss der Puffer im Kernel sein wo diese zu Daten zusammengestellt werden und wenn der Bug nun den hinteren Bereich überschreibt in diesem Buffer überschreibt, also da wo bei 4 Blocks keine Daten mehr stehen, dann ist Intel nicht beroffen aber alle anderen wären es. Man müsste das mal ausprobieren indem man den Wert entsprechend reduziert und schauen ob der Fehler nocht auftritt. Damit kann eben auch ein FW Update, welches dann statt 4 nun 8 erlaubt zum Auslöser werden und plötzlich ist die SSD betroffen und alle schwören es gäbe einen Bug in der neuen FW.

EDIT: Das Mißverständnis liegt ja im Treiber... gibt es verschiedene Treiber für verschiedene SSDs?

Nein, es gibt keine Samsung Treiber für die Samsung SATA SSDs, das ist Müll und egal ob die Systeme mit Intel oder Samsung betrieben wurden, der Treiber waren bei gleicher Linuxversion und -konfiguration auch die Gleichen. Keine Ahnung wer sich jetzt den Mist mit den Treiber ausdenkt, dass ist aber totaler Schwachsinn.

Das Problem der 840 EVO mit queued TRIM existiert zwar (übrigens gabs das Problem auch bei Crucial und ist bei der M500 nicht gefixt worden), aber der Patch stammt schon vom Mai und hat nichts mit dem Problem von Algolia zu tun.

Sicher? Wie gesagt sind alle Angaben zu Problemen nur dann zu gebrauchen, wenn die SSDs nicht im RAID liefen und alle wo man das nicht weiß, sollte einfach vergessen. Vermutlich kann da einiges aus der Blcklist und bei anderen wäre ich auch vorsichtig, ob der Bug wirklich in der FW liegt. Man auch mal dir Werte von Word 105 und 222 der Identify Device Data eine MX100/m550 mit MU01 und mit MU02 FW vergleichen, wenn sich da was geändert hat, war es kein Bugfix in der FW der SSDs, sondern nur um einen Bug bei Linux nicht zu triggern.

Aber es ist durchaus möglich das ein Fehler nur mit bestimmter Hardware auftritt und diese Hardware trotzdem nicht Schuld ist weil ihr Verhalten zwar anders aber trotzdem innerhalb der Spezifikationen liegt.

Wohl eher weil die Angaben zu den Fähigkeiten bei dem OS zu unterschiedlichen Arbeitsweisen und z.B. Puffergrößen führt. Wenn eine SSD angibt etwas nicht zu könne, dann wird das OS auch die entsprechenden Funktionen für diese SSDs nicht anwenden und es werden dann u.U. eben anderen Routinen durchlaufen in denen es einen bestimmten Bug vielleicht nicht gibt. Die sind ja nicht alle gleich und werden auch nicht alle gleich behandelt.

Soweit ich es in der Mailinglist gelesen habe, lag es sehr wohl an Samsung. Da diese sich nicht an die Spezifikationen gehalten haben!

Wo hast Du was gelesen? Die Mailinglist schreiben nur, was passiert und nicht wieso, genau wie der Blog von Algolia auch nur geschrieben hat was passiert ist, die Ursache war aber eben nicht die, die man vermutet hat, auch wenn es manche nicht einsehen oder verstehen können bzw. wollen.

Es liegt wohl daran, dass die SSDs die TRIM + NCQ nicht richtig verarbeiten bzw. sich an die Vorgaben halten.

Gibt es wirklich einen Bug in der FW der (Samsung) SSD mit Queued TRIM oder gibt es da bei Queued TRIM auch einen Bug im Linux Kernel? Oder waren die betroffenen SSDs Teil eines md-raid und der nun gefundenen Bug hatte dort zugeschlagen? Der hat aber wohl mit Queued TRIM aber nichts zu tun.

Mir ist völlig egal wer Schuld war. Ich hab Seit 6 Jahren nur Crucial SSDs in Betrieb, musste noch nie irgend etwas patchen, alles läuft wie geschmiert unter Win sowie unter Linux. Samsung, die gefühlt in den letzten Jahren 78 Patches veröffentlicht haben für ihre Produkte

Bei den SSDs gab es bei Crucial aber mehr FW Updates als bei Samsung und einige sollte man nicht auslassen, sonst trifft einen noch der 5184 Stunden Bug der m4. Da Samsung natürlich ein sehr viel größeres Produktangebote als Crucial hat, gibt es im ganzen halt auch mehr patches, aber nur auf SSDs bezogen waren es eben weniger und nur der Vergleich macht Sinn, oder hast Du ein Crucial Smartphone und einen Crucial Fernseher?

 

[Jesterfox]

Sicher? Wie gesagt sind alle Angaben zu Problemen nur dann zu gebrauchen, wenn die SSDs nicht im RAID liefen und alle wo man das nicht weiß, sollte einfach vergessen. Vermutlich kann da einiges aus der Blcklist und bei anderen wäre ich auch vorsichtig, ob der Bug wirklich in der FW liegt.

Na, zumindest wurde die Blacklist nochmal angepasst als Crucial Firmwareupdates gebracht hat, von daher kann man denk ich schon davon ausgehen dass die tatsächlich ein Problem hatten. Wie das bei den Samsungs ist bleibt da noch offen, aber die sind ja schon vor dem Vorfall auf der Liste gelandet, es muss also einen anderen Grund gehabt haben.

 

[Holt]

Wobei auch da unklar bleibt wie der Fix genau war und ob der Fehler wirklich in der FW der Crucial SSDs lag oder nicht am Ende einfach eine Weg gefunden wurde z.B. über andere Angaben in den Identify Device Data damit der Bug nur nicht mehr auftritt?

Das Problem liegt ja offenbar im Kernel daran, das der TRIM (discards) eben anders als Lese- und behandelt und bei TRIM Änderungen auf Adressbereichen im RAM erfolgen müssen, die bei Lese- und Schreiboperationen nicht erfolgen und daher nicht vorgesehen sind. Offenbar um Performance zu gewinnen hat man da wohl zwei Pointer auf den gleichen Adressbereich, was aber nicht gutgehen kann, wenn die Daten dan geändert werden:

Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing
the bio_vec between the two resulting bios. That is fine for read/write
requests where the bio_vec is immutable. For discards, however, we need
to be able to attach a payload and update the bio_vec so the page can
get mapped to a scatterlist entry. Therefore the bio_vec can not be
shared when splitting discards and we must do a full clone.

Da bleibt die Frage wo im Kernel sowas womöglich noch der Fall ist. Wie schon gesagt, hätte das Wachsen der Blacklist die Linux Entwickler schon stutzig machen müssen, denn wenn scheinbar Hunderte Geisterfahrer auf der Autobahn unterwegs sind, ist man selbst der Geisterfahrer! Wenn sehr viele SSDs mit unterschiedlichen Controllern / unterschiedlicher FW die gleichen Fehler in der FW zu haben scheinen, dann ist das eben für sich schon mal wenig wahrscheinlich und deutet darauf hin, dass der Fehler doch woanders liegen müsste. Auch die Tatsache das es bei der einen oder anderen SSD funktioniert reicht bei der Komplexität des Themas nicht als Beiweis für die Fehlerfreiheit der Implementierung aus.

 

[Seth666]

Meine M4 und alle die ich verbaut habe (werden so 20-30 sein) rennen seit 2009 pausenlos und ohne Probleme, Keine Ahnung vllt habe ich wirklich Glück gehabt und spätere Firmwares erwischt. Mit der MX100 hatte ich auch noch keine einzige Reklamation und auch selber noch keine Probleme. Mit Samsung habe ich hingegen schon sehr häufig sehr schlechte Erfahrungen gemacht. Egal was es war, Brenner, Drucker (wobei die noch am besten waren), Festplatten, SSDs: Alles immer wieder mit derben Fehlern gleich bei Ankunft. Ich hatte da mal nen M2675FN der frisch ab Werk eine Firmware hatte die einfach machte was sie wollte. Das war echt schon lustig was der Drucker veranstaltet hat. Das Ding ging zurück und erhalten habe ich ein Gerät mit kaputten Sensoren am Papierfach... Die SSDs, die ich verbaut hatte kamen glaube ich mitlerweile alle zurück, oder sind schon dank abgelaufener Garantie über die Wupper und durch funktionierende Elektronik ersetzt, also Samsung ist und bleibt einfach koreanischer Elektromüll. Geklaute Technik, stümperhaft zusammengeschustert und mit ner gehuddelten Software versehen: kurz Samsung.

Ich sage nicht, dass andere Hersteller keine Probleme haben, aber bei Samsung ziehts sich durch alle Sparten immer und immer und immer wieder. Über die Jahre fällt das halt echt auf.

Dieser Post spiegelt meine persönliche Meinung und Erfahrung wieder, die nicht jeder teilen muss. Alles klar?

 

[Corvus Corax]

...
Es stand auch schon eindeutig im Blog:
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?
......................

Danke für diesen höchst interessanten Artikel, 1 Doppel plus.

 

[Holt]

Meine M4 und alle die ich verbaut habe (werden so 20-30 sein) rennen seit 2009 pausenlos und ohne Probleme,

Nicht gegen die Crucial m4, ich habe selbst 4 Stück davon, aber die ist erst im April 2011 erschienen, wie Du die seid 2009 pausenlos im Einsatz haben kannst, beibt also ebenso ein Rästel wie die Glaubwürdigkeit des Restes Deiner Geschichte.

Die SSDs, die ich verbaut hatte kamen glaube ich mitlerweile alle zurück,

Auch das ist sehr unwahrschweinlich, da Samsung zu den SSD Herstellern zählt die in der Statisik bei hardware.fr immer die geringsten Ausfallraten haben, nur in der aktuellen Ausgabe ist Intel knapp vorbeigezogen.

Stümperhaft zusammengeschustert ist nur Dein dummer Bashingbeitrag hier!

 

[Wolfsrabe]

@Set666:
Klar, deine persönliche Meinung. Hat aber dennoch ausgerechnet in diesem Thema nichts zu suchen, wenn man ganz genau den Ausführungen folgen würde. Das ist so, als würde man in einem Thread, der sich um Pixelfehler eines LG-Monitors dreht, die Schuld nvidias 970er 3,5GB zuschieben, der an einem LG-Monitor hängt. Das passt genauso wenig.

@Holt: Danke, wie so oft, für die gründliche Aufklärung.

 

[Akusai]

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

WOW. Was für eine Arbeit. Ich habe nur kurz in die Patches reingeschaut, einigermaßen verstanden das es was mit Software RAID und den TRIM Befehlen zu tun hatte und das hat mir schon gereicht. Die ganzen BIO Pointer welche die Entwickler dann noch hinzugepatcht haben war mir dann schon zuviel.
Also: großes Doppel+ und danke für den Beitrag. Wieder mal was dazugelernt.

 

[Seth666]

Echt, erst 2011? - Ok mein Fehler- dachte ich hätte sie schon seit 2009 drinn. Dann wars halt 11. Bin der Letzte, der einen Irrtum nicht eingesteht. So oder so länger als 5000 irgendwas Stunden...

@Wolfsrabe und @Holt glaubt es oder lasst es, aber sprecht mir nicht mein Recht auf Meinungsäußerung ab.

Schönes Wochenende.

 

[Holt]

Wenn sie länger als so 5184 Stunden gelaufen sind, dann müssen sie entweder ein FW Update auf die 0309 oder höher haben, sonst gibt es regelmäßig Probleme weil die m4 sich nach einiger Zeit, etwa eine Stunde das schwankt wohl auch von Fall zu Fall einfach nicht mehr reagiert bis sie stromlos gemacht wird.

 

[blackiwid]

Und Du weißt offenbar auch nicht einmal was ein Kernel ist, noch trauriger.

schoen das du enteder dumm bist oder dich dumm stellst also ein troll bist. Der Kernel ist opensource es gibt keine Person oder auch keine juristische Person also eine Firma mit dem Namen.

Daraus ergibt sich das Samsung das testen konnte und haette muessen oder keinen Linux support mit bewerben sollen. Es gibt niemanden auf den sie die verantwortung schieben koennen.

Bei Microsoft ist das eventuell anders da hat samsung vielleciht kein zugriff auf den source da muesste man die verantwortund dann microsoft zu schieben.

Man kann drueber philosophieren ob andere ssd hersteller den bug auch haetten finden muessen, aber da ihre kunden davon wohl nicht betroffen waren warum auch immer, samsung hatte alle mittel den fehler zu finden und zu fixen wenn sie das nicht gemacht haben haben sie fahrlaessig gehandelt.

btw auch wenn die firmen kein zugriff auf den source haben wird ihnen die schuld zu geschrieben jedes speil das mit amd hardware schlecht laeuft wo ein proprietaerer shader von nvidia das problem ist, faellt auf AMD zurueck in dem fall ungerechterweise aber seis drum. Samsung aber gerechterweise3 da ihnen niemand den source vor enthalten hat.

 

[Seth666]

@holt

Wie gesagt, keine Ahnung welche Firmware da drauf war, evebtuel hab ich echt x- mal Glück gehabt aber ich hab keine Klagen gehört und meine M4 läuft wie en 1 unter Linux mint und vorher jahrelang unter Windows.

 

[Holt]

schoen das du enteder dumm bist oder dich dumm stellst also ein troll bist. Der Kernel ist opensource es gibt keine Person oder auch keine juristische Person also eine Firma mit dem Namen.

Das ist mir seid mehr 20 Jahren klar, als ich den Linux Kernel zum ersten mal auf meinem Amiga kompiliert habe, aber Du bist hier der Troll dern sind ja dafür bekannt alles zu verdrehen um die Verdrehung dem anderen anzulasten und dann über die eigenen Blöd- oder Gemeinheit als lächerlich hinstellen zu wollen.

Du hast geschrieben:

dann ploetzlich sei der Kernel schuld, wer auch immer dieser Herr Kernel ist.

Und Du weißt offenbar auch nicht einmal was ein Kernel ist, noch trauriger.

Dabei habe ich wenigstens noch einen Simlie gesetzt, für den Fall das Du den vergessen hast, aber das glaube ich kaum, denn die Aussagen passt jetzt noch besser ins Gesamtbild als vorher, weil Du ja nun sogar Samsung für die Bugs im Linuxkernel verantwortlich machst. Aber der Linuxkernel ist nicht von Samsung und da gibt es auch keinen Treiber von Samsung, die haben dafür genau NULL Verantwortung, außer sie haben explizit die Tauglichkeit der SSDs für die bestimmten Linux Kernelversionen mit mdraid und TRIM versprochen.

 

[blackiwid]

Komplettzitat entfernt

von wem ist er dann 99% ist von firmen verschiedenen, jeder vall sich beteiligen, wenn man das dann nicht tut soll man nicht mit linux support werben denn dann gibt man keinen support.

wenn der freie amd grafikkartentreiber im kernel buggy ist geb ich auch nur amd die schuld sonst niemand anderem.

Aber schon klar ist halt linus torvalds schuld oder die boese opensource verschwoerung oder sonst wer der Mann im Mond. Und linux ist eh scheisse das wollten wir eh alle schon immer mal sagen.

 

[Holt]

von wem ist er dann 99% ist von firmen verschiedenen, jeder vall sich beteiligen, wenn man das dann nicht tut soll man nicht mit linux support werben denn dann gibt man keinen support.

Kann das mal jemande auf Deutsch übersetzen, ich verstehe bei besten Willen nicht, was der Baching-Bot mit sagen will.

wenn der freie amd grafikkartentreiber im kernel buggy ist geb ich auch nur amd die schuld sonst niemand anderem.

Der ist auch von AMD und Grakas brauchen auch einen Treiber, aber bei SATA Platten braucht nur der SATA Host Controller einen Treiber, nicht jede Platte! Das ist bei Windows und Linux das Gleiche, oder hast Du schon mal einen Treiber von z.B. Crucial, HGST, Plextor, Kingston, WD, SanDisk, Seagate Transcend oder Toshiba für deren SATA HDDs oder SSDs installieren müssen? Da gibt es allenfalls Diagnosetools um den Zustand der Platte zu testen und anzuzeigen und bei SSDs in letzter Zeit vermehrt diese blödinnigen Toolboxen mit den noch unsinnigeren RAM Cache Lösungen, aber das ist alles optinal und unnötig. Treiber brauchst Du aber von Microsoft (dem OS Hersteller) oder Du nimmst die von Hersteller des SATA Host Controllers, der ggf. im Chipsatz steckt, also von z.B. AMD, ASMedia, ASUS, Intel, NVidia oder VIA. Schau doch mal mit Drive Controller Info ob da ein Crucial, Samsung, Seagate oder WD Treiber angezeigt wird!

Und linux ist eh scheisse das wollten wir eh alle schon immer mal sagen.

Nein Linux ist nicht scheisse, es ist aber eben auch nicht perfekt und komplett fehlerfrei, wie die Fanboyse es ihm gerne unterstellen würden. Es hat auch seinen Grund warum die Enteprise-Linux Versionen meist auf alten bis sehr alten und eben entsprechend gut getesteten, nicht selten auch vom Anbieter merhfach gepatchten Kernels basieren. Wer auf Stbilität wert legt, kann und will eben nicht immer mit den neusten Versionen das Versuchskaninchen spielen. Algolia wird das auch noch lernen (müssen).

 

[blackiwid]

@Holt
Nur weil etwas unter windows so und so ist sagt das ueber linux genau nix aus. Linux das entwicklungsmodell dahinter funktioniert anders.

Nur wenn alle ihre fehler finden und patches senden oder bug reports aussagekraeftige funktioniert es und wenn dafuer das samsung in keinem testsystem gefunden hat bevor es verkauft wurde ist das ein fehler der in der Qualitatskontrolle passiert ist nicht so dramatisch firmen benutzen heufiger backups wie privatleute und wenn nicht selber schuld aber klar wenn der betribb wo unterbrochen wird kostet das geld und sollte sowas immer noch sofern bekannt samsung spezifisches nochmal vor kommen werden sicher einzelne firmen ueberlegen ob sie samsung ssds kaufen.

Den absatz oben kann man super lesen wenn du das 'wort' vall durch kann ersetzt kaempte wohl mit tastaturlayoutwechsel.

 

[Wolfsrabe]

@Holt:
Dem muß nichts hinzugefügt werden.

@seth666: Hab dir deine freie Meinungsäußerung nicht verwehrt und das hab ich auch gesagt (im ersten Satz). Aber du mußt lernen, daß es bei faktisch fehlerhaften Aussagen seinerseits passieren kann, daß man dir mit Korrekturen entgegenkommt. Ganz einfache Logik.

 

[Holt]

@Holt
Nur weil etwas unter windows so und so ist sagt das ueber linux genau nix aus. Linux das entwicklungsmodell dahinter funktioniert anders.

Das Hardwaremodell ist aber das gleiche und der Sinn von genormten Anschlüssen für Massenspeicher wie eben SATA oder SAS ist ja gerade genau, dass man für die Laufwerke keine Treiber braucht, sondern nur für die Host Controller, von denen es aber nun einmal ungleich weniger Auswahl gibt, was die Sache vereinfacht. Da meines Wissens auch viele Hersteller von SATA Host Controller auch gar keine eigenen Treiber für Linux anbieten, müssen diese also mit dem Linux eigenen Treiber auskommen. Der dürfte wie der Treiber von Microsoft auch auf dem Standard für AHCI ausbauen und mit jedem Standardkonformen AHCI Host Controller funktionieren, dafür unterstützt es eben dann besondere Features einzelne SATA Host Controller nicht, aber das macht ja auch nichts.

Das ist bei USB auch das gleiche, da funktionieren auch alle USB Stick und USB Festplatten ohne eigene Treiber, die braucht man dann allenfalls für Zusatzfunktionen wie z.B. Verschlüsselung oder diese One Button Backup features, aber die Platte funktioniert auch ohne, denn es gibt in Windows einen Standardtreiber für alle USB Massentreiber und kein Hersteller bietet da einen eigenen an, außer den UASP, aber die kommen auch vom Hersteller des USB Host Controllers.

Nur wenn alle ihre fehler finden und patches senden oder bug reports aussagekraeftige funktioniert es und wenn dafuer das samsung in keinem testsystem gefunden hat bevor es verkauft wurde ist das ein fehler der in der Qualitatskontrolle passiert ist nicht so dramatisch firmen benutzen heufiger backups wie privatleute und wenn nicht selber schuld aber klar wenn der betribb wo unterbrochen wird kostet das geld und sollte sowas immer noch sofern bekannt samsung spezifisches nochmal vor kommen werden sicher einzelne firmen ueberlegen ob sie samsung ssds kaufen.

Hier hat der Samsung-Bash-Bot wieder unverständlichen Mist zusammengesponnen, das einzige was man da halbwegs verstehen kann ist, was von Samsung spezifisch, aber auch das ist es ja nicht, es ist ein Bug im Linux Kernel und der kann sehr wahrscheinlich von anderen SSDs genauso getriggert werden, es stehen ja auch Crucial/Micron SSDs in der Blacklist und da man nicht weiß ob dort der Fehler nicht womöglich auch bei Konfigurationen im mdraid aufgetreten ist, kann es sein das der Bugfix von Crucial am Ende nur eine Umgehung der Probleme durch andere Identify Device Data ist, statt wie Samsung den Kernel zu debuggen.

Für so eine Debugaktion dürfte Micon/Crucial vermutlich die Kompetenz fehlen, die haben ja außer Treibern für die paar PCIe Enterpise SSDs (deren Controller auch zusammen mit IDT entwickelt wurde) und SSD FW keine große SW-Entwicklung, die machen ja nur RAM und SSDs, bei die Schwesterfirma Lexar auch Speicherkarten und USB Sticks, also alles nichts wobei man mit dem Linux Kernel in Berührung kommen müsste.

Den absatz oben kann man super lesen wenn du das 'wort' vall durch kann ersetzt kaempte wohl mit tastaturlayoutwechsel.

Kann mal jemand bei der Spamfima diese diese Beiträge einsetzt diesen Bot ausschalten, zumindest bis es mal debuggt wurde, da scheint es im Kernela ja mehr Bugs zu geben als im Linux Kernel.

@All, es könnte vielleicht mal jemand die Identify Device Data der m500 oder besser MX100/m550 mit MU01 und MU01 und eines m550/MX100 mit MU02 FW posten. Das geht mit CrystalDiskInfo (die Portable Standard Edition reicht und ist frei von Werbung, einfach dem Link folgen, die zip speichern und irgendwohin komplett entpacken, dann DiskInfo.exe dort starten), dort die SSD auswählen und dann unter "Bearbeiten" "Kopieren" oder einfach Ctrl+C. Das dann bitte im Tag

 Posten oder mit mailen. Danke!

PS: Integrated Device Technology, Inc.'s (IDT) wurde von 2013 von PMC-Sierra übernommen und der PMC-Sierra PMC 89HF16P04CG3 SSD Controller steckt z.B. auch in der XS1715, wie in manch anderer Enterprise PCIe NVMe SSD, da dürfte wohl klar sein, wer wie viel Anteil am der Controllerentwicklung für die Micron P320h hatte, deren Controller ein dem NVMe praktisch identisches Protokoll nutzt.

PS2: Wo bewirbt Samsung seine SSD im Zusammenhang mit Linux? Das einzige was [URL=http://lmgtfy.com/?q=site%3Asamsung.com+ssd+linux]google mir dazu ausspuckt[/URL] ist der Hinweis, dass das Samsung Magician Tool nur für Windows verfügbar ist und die Nutzer von Linux und Max OX S dann ein FW Update über das ebenfalls verfügbare ISO Image machen müssen. Samsung trägt genau 0 Verwantwortung für Bugs im Linux Kernel, auch wirklich kar keine. Es steht sogar unter den Systemvoraussetzungen Windows drin:[QUOTE][URL=http://www.samsung.com/de/support/skp/faq/1031938] Welche Systemvoraussetzungen müssen erfüllt sein, um meinen PC oder mein Notebook mit einer SSD betreiben zu können?

Last Update date : 2014.02.08

[B]Um eine SSD in ihrem PC oder Notebook nutzen zu können sollten folgende Voraussetzungen erfüllt sein: 
[/B]
-  Ein freier SATA-Anschluss 
-  Unterstützung von SATA 3 Gb/s (SATA II)* 
-  Unterstützung von AHCI durch das BIOS/UEFI** 
-  Leistungsfähiger Dual-Core Prozessor (z.B. Intel Core 2 Duo) oder höher*** 
-  [B]Betriebssystem: Mindestens Windows Vista mit Service Pack 2 oder höher, Windows 7, Windows 8 oder Windows 8.1[/B]****/*****

Anmerkungen:

* Beachten Sie bitte, dass bei der Verwendung von SATA 3 Gb/s nicht die volle Leistungsfähigkeit des SSD erzielt werden kann. Um das volle Potenzial der SSD auszuschöpfen empfehlen wir den Anschluss der SSD an einen SATA 6 Gb/s (SATA III) Port.

** Eine Nutzung der SSD im sogenannten IDE-Modus ist zwar generell möglich, geht allerdings mit  Leistungseinbußen einher. Daher raten wir von der Verwendung einer SSD im IDE-Modus ab.

*** Bei Verwendung leistungsschwächerer Prozessoren kann nicht die volle Leistung der SSD abgerufen werden. Die Verwendung einer Samsung SSD in Verbindung mit solchen Prozessoren wird nicht empfohlen.

**** Die Verwendung einer SSD in Verbindung mit Windows XP ist generell möglich. Beachten Sie jedoch, dass Windows XP das TRIM-Kommando nicht unterstützt, welches für den Erhalt einer hohen SSD-Performance benötigt wird. Hier ist es notwendig, die Leistung der SSD regelmäßig manuell über die Samsung Magician Software zu optimieren. Der entsprechende Menüpunkt für die Optimierung der SSD-Leistung in der Magician-Software lautet „Performance Optimization“.


***** Generell kann eine Samsung SSD auch in Verbindung mit einem GNU/Linux Betriebssystem (z.B. Ubuntu) sowie Mac OS betrieben werden. Beachten Sie jedoch, dass unter GNU/Linux eventuell manuelle Anpassungen am Betriebssystem vorgenommen werden müssen, damit das TRIM-Kommando regelmäßig ausgeführt wird. Beachten Sie bei der Verwendung von Mac OS, dass zusätzliche Programme von Drittanbietern installiert werden müssen, die den TRIM-Befehl unter diesem Betriebssystem aktivieren. [/URL][/QUOTE] Das schließt eine Nutzung unter Linux zwar nicht aus, ist aber nach meinem Verständnis nun wirklich alles andere als werben dafür die SSD unter Linux einzusetzen wenn dort steht, es sollten folgende Voraussetzungen erfüllt sein und nur Windows Betriebssysteme aufgezählt werden.

 

[Wolfsrabe]

Also ganz ehrlich, dafür, daß Samsung offenbar wenig mit Linux am Hut hat, wie Holt am Beispiel der Systemvoraussetzungen zitiert hat, haben sie sich verdammt ins Zeug gelegt mit dem Kernelpatch.