[Gelöst] Samsung 840 EVO - 3.16.7-21-desktop;

Die Lösung als Kurzfassung im ersten Beitrag:

Ein Kernelupdate auf 3.16.7-24 das zwischenzeitlich aus dem Updaterepo bezogen werden kann bringt einen Patch für die SSD mit. Dieser behebt meine schlimmsten Probleme und ich kann entspannt auf die Zukunft mit dieser SSD blicken.

- Meine Sorge um die Qualität der SSD ist auch gelöst.
- Ich verwende kein "discard"
- Dafür habe ich mich entschieden einmalig wöchentlich einen Trim per cronjob zu starten.
Den cronjob hier nochmal, dass nicht nachgelesen weden muss:
Anlegen als ausführbar: /etc/cron.weekly/trim.sh

Code:

#!/bin/sh
LOG="/var/log/TRIM.log";
TEXT="Trim wurde gestartet bitte prüfe $LOG";
wall -n $TEXT
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG

Wer trotzdem noch mitlesen will, wird fast nur noch offtopic finden

Vielen Dank für die Hilfe an dieser Stelle nochmals. Guter Rat und Erfahrung ist verdammt wichtig.

#######################


Hallo.

Ich würde euch da mal gerne drauf loslassen:

FIRMWARE: EXT0DB6Q
Verwendeter Kernel: 3.16.7-21-desktop;

Ich verwende weitestgehend "ext4";

Bezüglich der SWAP:
Hinzugefügt in: "/etc/sysctl.conf"
Im computer hängen noch weitere Festplatten:
SSD mit und nur für Windows;
1 Hotplug fähiger Wechselrahmen
1 WD 1 TB HDD;

Ich habe mir den SAMSUNG Magician für Linux Heruntergeladen. Ich überlege gerade ob ich den Trimbefehl via der Binary as crondaily ablege. Ich weiss allerdings "NICHT", was der unterschied zwischen dem trim vom samsung magician zum normalen fstrim ist und was sinnvoller ist.

Die binary ist für mich sehr undurchsichtig, ich kann nicht sehen wie sie was macht. Nur dass sie was macht. Laut SAMSUNG ist "OP" für meine SSD ca 5% das heisst ca. 10,9 GB. Das habe ich bereits mit dem Magician eingestellt.

Mit "discard" kann ich wegs eines firmware bug nicht arbeiten, da die EVO behauptet trim mit ncq zu können. Da spinnt meine 840 EVO damit, rastet total aus bekommt "freeze" und im schlimmsten fall wurde mir schon "/home" zerschossen;

Es gibt aktuell wohl eine Entwicklung dazu dass bestimmte Geräte wegen dieser Funktion in eine Blacklist aufgenommen werden. Diesen Patch gibt es aber in dem von mir aktuell verwendeten Kernel noch nicht. Dazu müsste ich einen Bugreport erstellen und um Portierung bitten.

Das empfinde ich allerdings nicht als absolut notwendig, da ich nicht mit "discard" arbeiten muss. Ich kann ja mit meinem cronjob arbeiten.

Ausserdem habe ich ja eine SSD HDD mixed umgebung, deswegen möchte ich NCQ nicht völlig abschalten.

EDIT:
#### Funktioniert noch nicht: (SIEHE 3. POST)
cat /etc/cron.daily/trim
##### Funktioniert noch nicht
/EDIT

Über Tipps und Erfahrungen würde ich mich dennoch freuen.

Hier noch der Link zum magician und anleitung:
http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/server_downloads.html

Dann möchte ich noch sagen, dass ich gänzlich auf laptop-mode tools tuned usw. verzichte.

Ich habe powertop verwendet und mir die tunables zusammengescriptet;
https://01.org/sites/default/files/page/powertop_users_guide_201412.pdf

Das Ergebnis starte ich via RCLOCAL. Rückwirkend hab ich mein Keyboard und meine Maus wiederum soweit aktiviert, dass ich den Computer aus s2ram damit aufwecken kann. (Mein script fordert auch USB forciv auf zu schlafen). Deswegen werden UDEV rules da diese früher gesetzt wurden als das SCRIPT nicht gewürdigt.

Weiter habe ich das Problem, da alle Festplatten von anderen Herstellern sind und teils propritäre Standby modi mitbringen, die von den tuned und laptopmode tools etc und auch von hdparm teils nicht richtig gesetzt werden können. Unter anderem da beispielsweise die Western digital ganz eigene protokolle verwendet. Was gehen würde ist:
Weil sonst jeder was anderes macht. Dennoch löst "vendor specific" aus, dass die eine platte vollgas durchläuft und die andere einschläft und die wieder nächste will das au nicht. Und das ist mit den standard tools nicht kompatibel. Und entspricht nicht meinen vorstellungen.

Was aber geht ist das:
Deshalb habe ich einen cronjob, der alle 5 minuten läuft.
hdparm -y also der Standby - Befehl geht bei allen meinen Geräten.

Hier der script: http://zackreed.me/articles/85-spin-down-idle-hard-disks-without-hdparm

Bei mir nur alle 5 Minuten. Und die ungenutzen Festplatten schlafen. Jetzt ist Ruhe im silent PC.

Gruß,

R

Da kann ich Dir nur mein Beileid zur 840 EVO aussprechen, der einzigen mir bekannten SSD, die mit der Zeit die Daten vergißt. Samsung hat zwar mit der von Dir genannten firmware Abhilfe in der Form geschaffen, daß jetzt die Daten - die Lebensdauer der SSD reduzierend - regelmäßig umkopiert werden, ganz ohne Datenverlust wollte man aber wohl nicht auskommen, darum wurde eingeführt, daß ein solcher jetzt bei queued TRIM erfolgt.

Da die SSD behauptet, queued TRIM zu beherrschen, wird es sowohl mit discard als auch mit fstrim ausgeführt. Möglicherweise führt das Programm von Samsung ein "normales" TRIM aus, aber diesbezüglich solltest Du Dich schlau machen.

NCQ kannst Du auch für einzelne Platten deaktivieren (Kernel-Parameter libata.force=2:noncq für ata2 oder eine udev-Regel, die das Attribut queue_depth auf 1 setzt), welche Nachteile Du Dir damit einhandelst, mußt Du Samsung fragen.

Künftige Kernel dürften den Parameter libata.force=2:noncqtrim kennen, beim 4.1er ist es noch nicht der Fall.

Hallo.

Danke für die Infos. Das Detail hätte ich garnicht gewusst. Mit dem magician muss ich nochmal separat angehen.

Jetzt hab ich hier noch etwas relativ banales.
Ich hab mir das gestern eingerichtet und heute bekommt root eine email:

Wenn ich den script als root ausführe läuft er duch. Ich gehe davon aus, dass es an den Berechtigungen liegt.
Ich hab ihn jetzt so in crontab eingetragen und aus /etc/crond.daily entfernt:
Jetzt liegt er im pfad wie in dieser zeile und schaut immernoch so aus:

Weil ich glaube es ist so, dass die crontab von root entsprechend berechtigt sein wird und die crondaily eventuell nicht? Oder liegt es an was anderem?

Wird der "@daily" dann auch nachgeholt, wenn ich den computer erst um 18 uhr einschalte?

Vielen Dank!

Gruß,

R

Noch einmal:

josef-wien schrieb:

Da die SSD behauptet, queued TRIM zu beherrschen, wird es sowohl mit discard als auch mit fstrim ausgeführt.

Zum Vergrößern anklicken....

Schau Dir dmesg bzw. journalctl (oder was immer bei Dir verwendet wird) an.

Also bei DMESG und bei journalctl -b usw is eigentlich alles ok soweit. Das Problem ist denke ich tatsächlich nur, dass es einmal möglich ist trim in Verbindung mit NCQ auszuführen. Und dann gibt es noch die Möglichkeit TRIM ohne NCQ.

Kennst du dich zufällig mit cron aus?

Gruß,

R

Cron ERLEDIGT!

Hab s gerade nochmal ausprobiert. /var/spool/cron/lastrun/cron.daily gelöscht und den script nochmal platziert.
Dann mit run-crons abgefeuert und jetzt lief es durch ohne Fehler und die E-Mail war sauber.

Hoffe das mit cron ist dann erledigt.

Jetzt hab ich aber noch etwas, das keinen Spass macht:

Komisch die Meldung trat bei einem Warmstart (Wechsel von WIN 10 auf SUSE 13.2) auf. Nach kaltstart kam sie nicht mehr.... :???:

edit: Komisch - so nicht reproduzierbar ----- /edit:

edit:
Nicht reproduzierbar.... jetzt habe ich nach einiger vergangener zeit meine Script wieder abgefeuert und erhalte auf einmal wieder den fehler:

/edit

Werde dann doch versuchen, das NCQ abzuschalten.
Werds erstmal damit versuchen wie von josef-wien vorgeschlagen:
Es erscheint beim boot mit dem switch die Meldung:
Also wohl erfolgreich eingetragen. (Muss ich beobachten).

Ist eigentlich mit horkage das gemeint?
https://en.wiktionary.org/wiki/hork
Oder irgendwelche ninja skills?

revealed schrieb:

Also wohl erfolgreich eingetragen.

Zum Vergrößern anklicken....

muß 1 ergeben.

Von der reinen Lehre her kannst Du auch ohne Parameter starten und im Skript das Attribut auf 1 und am Schluß wieder zurück auf den ursprünglichen Wert setzen. Deine Fehlermeldungen über das nicht erfolgreiche queued TRIM wirst Du sehr oft im Internet finden (rein theoretisch kann ich mir vorstellen, daß die SSD damit zurechtkommt, wenn gerade nichts anderes anliegt, aber für diese Idee habe ich keinerlei Grundlagen). http://www.catb.org/jargon/html/H/horked.html scheint mir am nächsten zu kommen.

Vielen Dank!

muß 1 ergeben.

Zum Vergrößern anklicken....

Aktuell mit switch ist das Ergebnis: "1"

Das klingt sehr interessant!

/sys/class/block/sdb/device/queue_depth

Zum Vergrößern anklicken....

Müsste man da nicht libata neuladen?

Oder würde die (node?) den wert im Fluge akzeptieren?

Also in etwa:
echo wert -ziel
script
echo alter wert ziel?

Und was ich noch nicht weiss, woran sich die queue depth fest macht.
http://www.samsung.com/global/business/semiconductor/minisite/SSD/downloads/document/Samsung_SSD_840_EVO_Data_Sheet_rev_1_1.pdf
Oder wird das libata irgendwie selbst entscheiden?

Wenn ich mir das hier so anschaue:
https://www.thomas-krenn.com/de/wiki/Datei:Linux-io-deadline-scheduler.png
Dann komm ich irgendwie auf den Gedanken, dass ist n Firmware fehler?

Grüße,

R

... also doch ca95 ... ich musste nach dem Wort gerade echt in einem dict suchen und habe es zunächst nicht gefunden.

PS.: Wenn ich den switch rausnehme steht der Wert auf: Und in dmesg erscheint:
Und das reflektiert sich in meinen Augen mit dem QD32 aus dem Datenblatt.
Auch der Wert Sectors entspricht der Ausgabe von samsung_magician.

.... blockgeräteverschlüsselung (dm crypt) habe ich nicht eingerichtet.


Habe etwas gefunden.
https://de.manjaro.org/index.php?topic=3237.0
Das liest sich interessant! Ich entferne jetzt den SWITCH und setze das alpm vom SATA host von nur dieser SSD auf "max_performance".
Und schliesse sie aus meinem festplatten abschalte script aus.

Man stelle sich vor dass die festplatte gerade in den standby geschickt wird während trim ausgeführt wird und die queue könnte sich deswegen beschweren?

Aber das hier juckt ihn garnicht:
jetzt kann ich es echt nicht mehr reproduzieren hier... was n nu?
ALPM an / aus -- läuft sauber durch. WIe ich find ich das blos?

revealed schrieb:

woran sich die queue depth fest macht

Zum Vergrößern anklicken....

An dem, was sowohl Kernel als auch SSD können. Das Attribut ist im laufenden System änderbar, sofern es nicht durch den Kernel-Parameter auf 1 festgeschrieben wird.

revealed schrieb:

komm ich irgendwie auf den Gedanken, dass ist n Firmware fehler

Zum Vergrößern anklicken....

Ist mein erster Absatz vom 5. August 2015, 16:19 Uhr, zu ironisch-sarkastisch? Der Fehler wurde mit EXT0DB6Q neu eingeführt. Eine vorhergehende Version ist aber nicht sinnvoll, denn dann werden die Speicherzellen nicht regelmäßig umkopiert und es kommt mittelfristig zu Datenverlusten. Die bei den 840 EVO verwendeten Speicherzellen sind eine Fehlkonstruktion.

revealed schrieb:

Habe etwas gefunden

Zum Vergrößern anklicken....

Was hat das mit dem Problem zu tun?

Sporadisch:

SError: { PHYRdyChg CommWake }

Zum Vergrößern anklicken....

- in dem genaueren zusammenhang der Fehlermeldung sei ein Kabeldefekt oder ein stromausfall o. dgl.
Und die sporadische "ioctl" meldung bei fstrim...

Allerdings kann ich die stelle nicht reproduzieren bisher.

Danach suche ich gerade. Ich "teste heute mal nur mit kernel switch also queue depth "1". Ob Meldungen auftreten.
Root wird schon mail bekommen.

Morgen teste ich dann ohne switch. Wenn dann eine Meldung kommt, da ich diese gestern nicht mehr ohne switch reproduzieren konnte ---> teste ich übermorgen ob ein script wo ich die QUEUE depth setze funktionieren würde.

Und wenn das nichts hilft, dann aktiviere ich den Kernel switch, weil so schauts ja bisher relativ ok aus und gebe mich evtl. geschlagen.

Weil mit einem Bugreport im BUGZILLA ---- wenn ich damit dort anfange. (Ich find das ja selber bald lachhaft). Da würd ich mir selbst überlegen ... (WONTFIX)? Glaube nicht, dass daran ernsthaftes Interesse bestehen würde. Des is ja nicht gerade der eingebaute Rechenfehler von einem P1.

Leider bleibt mir nichts, als die SSD so lange zu nutzen wie sie funktioniert. Bei einer zukünftigen Anschaffung werd ich vorher anders planen.

Ursprünglich hatte ich die angeschafft, um jeweils mein aktuelles Computerspiel darauf zu installieren mit sehr hoher Verfügbarkeit und kurzen Ladezeiten. Kürzlich ist sie freigeworden, da ich meine Spieletiteldurst weitesgehend gestillt habe. Also GTA5 usw. ist wieder langweilig.

Und mein lokaler dealer hatte die halt sehr sehr günstig preis/leistung eigentlich ok rumliegen.

Dann hab ich Linux von HD jetzt auf die SSD.
Die HD könnte ich zur Not auch gleich anfeuern. Steckt aktuell (halb) im Wechselrahmen. (Fallback).

Ich hab aber gesamt so den verdacht, dass es die vollständig zuverlässige funktionierende SSD aktuell eh nicht gibt.

Vielleicht schauts in 1 - 2 Jahren auch anders aus. Und daweil möchte ich mit dem weitermachen, was ich zur Verfügung habe.

Gruß,

R

Also das thema SSD empfinde ich grad so wie "das ganze Betriebssystem in den RAM laden". Und hoffen dass kein Stromausfall kommt.

revealed schrieb:

Ich hab aber gesamt so den verdacht, dass es die vollständig zuverlässige funktionierende SSD aktuell eh nicht gibt.

Zum Vergrößern anklicken....

Zumindest nicht von Samsung.

Bin mal gespannt, was du mir antworten würdest wenn ich dich dann anschreibe und sage ich brauch ne gute

Also das Steht jetzt aktuell nicht im Raum. Weil ich diese hier jetzt erstmal durchtreten werde.

Gruß,

R

revealed schrieb:

Bin mal gespannt, was du mir antworten würdest wenn ich dich dann anschreibe und sage ich brauch ne gute

Zum Vergrößern anklicken....

Nee, nee. Wenn der Hersteller dann die Firmware ändert und einen neuen Fehler einbaut, bekomme ich die Schläge.
Letztes Jahr war nämlich Crucial das Problemkind und Samsung die Lösung. — Heute ist es genau umgekehrt.

Soll ich Dir was sagen?
Früher waren mir die SSD-Preise zu hoch und die Speicherzellen zu wenig robust.
Heute sind SSDs erschwinglicher aber dafür teils sehr schlampig programmiert.

Also besitze ich bis heute noch gar keine SSD. Ich bin doch kein Versuchskaninchen.
Und so richtig profitieren, kann ich von einer SSD für meine Zwecke noch nicht.
Aber andere Leute und andere PCs tun dies.

Also das Steht jetzt aktuell nicht im Raum. Weil ich diese hier jetzt erstmal durchtreten werde.

Zum Vergrößern anklicken....

Durchtreten, mit den Füßen?

Durchtreten, mit den Füßen?

Zum Vergrößern anklicken....

... nein. Also das läuft schon schnell so, auch mit queue depth 1 ist das schon erheblich flotter als eine herkömmliche HDD.

Vielleicht tut sich ja noch was und daweil kann ich versuchen noch was rauszukitzeln. Aber ich werd des teil nicht gleich wegwerfen. Es besteht eventuell noch die möglichkeit dass Samsung nochmal nachbessert via Firmware? (Wer weiss das schon). Umtauschen ist jetzt gemessen an der Zeit die ich das Teil jetzt schon im Windows im Einsatz hatte eh nicht mehr.

Und Linux heisst nicht wirklich Rente. Sondern neuer Job.

Also mit switch lief echt gut heute bisher (auch der trim via cron daily).
Morgen dann das ganze ohne switch (nochmal sehen wann und warum das auftritt -- falls überhaupt nochmal).
Und übermorgen ohne switch mit geändertem Script. (Das Script werde ich aber hier erst mal nicht posten). Vielleicht falls es funktionieren sollte. Wobei das dann aber äusserst abenteurlich wäre.

Gruß,

R

Was spricht denn aktuell gegen ein Update auf Linux Kernel 4.1?
Dort wird gemäß Blacklist nur für die TRIM-Funktion die ATA Native Command Queue auf 1 gesetzt.

libata-core.c schrieb:

/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },

Zum Vergrößern anklicken....

Du wirst doch eh sicher im Spätherbst auf openSUSE Leap 42.1 umsteigen wollen, oder? Es verwendet auch Linux Kernel 4.1.

Dagegen spräche im Grunde nichts, wenn er denn schon ausgereift genug wäre. Und wenn ich sicher sein könnte, dass er mit dem rest der verwendeten Pakete stabil läuft. Ja das Upgrade werde ich dann im Spätherbst sehr gerne durchführen.

Mir fällt gerade auf:
Der Rechner ist nichtmal den ganzen Tag gelaufen. Und dann schreibt er bei einem mal Trim 70,8 GB Daten umher?
Also er schmeist aus 70,8 GB halbe blöcke -- ganzen zusammen --- ? Obwohl sich auf dem ding fast nichts gerührt hat heute?

Das verwirrt mich jetzt aber dann doch.

Gruß,

R

Dieser Fehler erinnert mich irgendwie an avd700. :schockiert:
—
21,1 GiB + 49,7 GiB = 76 GB.

Ich weiss nicht ich weiss nicht..... aber meine SSD geht in den "freeze" wenn ich NCQ Trim mache, glaube ich - wenn ich es richtig gesehen habe.
--- Aber nicht reproduzierbar.

Und heute lief er mit queue depth 1 komplett sorgenfrei durch.

Und mein Rechner friert davon nicht stundenlang ein und macht dann mal wieder.... Sondern hakelt kurz und rennt weiter.

... 70,8 GiB ich bitte um Verzeihung. ps:


Gruß,

R

revealed schrieb:

Und dann schreibt er bei einem mal Trim 70,8 GB Daten umher?

Zum Vergrößern anklicken....

Das ist völlig korrekt. fstrim analysiert das Dateisystem und meldet alle zu diesem Zeitpunkt aus Sicht des Dateisystems freien Sektoren an die SSD.

Angenommen ich wollte noch KERNEL:HEAD versuchen.

Passt das so? In /etc/zypp/zypp.conf

Dann bleibt doch mein momentaner Kernel aus Update erhalten und die anderen werden parallel installiert?

Gruß,

R

@revealed
Mir fällt gerade ein, dass Du ja den Linux Kernel 4.1 parallel zum Kernel 3.16 installieren kannst.
Beim Start lässt sich dann in GRUB2 einer der beiden Kernel fürs Booten auswählen.
Und Du musst doch nicht jeden Tag trimmen, oder?

multiversion = provides:multiversion(kernel)
ist schon von Haus aus aktiv.

multiversion.kernels = latest,latest-1,oldest,oldest+1,running
ist auch möglich.