• Ich lasse bei der Partitionierung meiner SSDs etwa 5% unpartitioniert (Reserve), damit einige schlechte Blocks Reserve sind.

    Das bieten die diversen Dashboards (Samsung: Magician) auch an, als "Over-provisioning". Wenn man in einem Partitionstool dann nachsieht, macht das einfach einen unpartitionierten Bereich nach der eigentlichen Partition. Bringt bei mir nur leider den grub durcheinander, auch mit EFI: die dahinterliegende Linux-Partition findet er dann nicht mehr.

  • grub merkt sich die Position nicht nach Partitionen, eher nach Sektoren. Danach fehlt evtl nur ein grub install ..


    Aber das hilft Dr. Seltsam jetzt nicht weiter.

  • Die Partition-UIDs sollten es eigentlich sein. Ok, danach wohl sucht grub bei update-grub, und trägt dann die entspr. Sektoren ein.

  • Moin,

    dumme Frage aber so banale Sachen wie defektes Kabel hast Du sicher ausgeschlossen, oder?

    Viel Glück wünscht

    Ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

  • Die SMART Values Deiner Samsung SSD sind, naja, wenig hilfreich.

    Das sind aber die bei Samsung üblichen.

    Die liefert meine 840er auch:

    Ich interpretiere 12% wear level, alternativ 88% "to go", je nach Standpunkt ... würde gegen erreichte TBW sprechen.

    Den RAW-Wert kann man hier wohl vergessen.

    115 machen für mich als Prozent-Wert keinen Sinn.


    Nach VALUE zu urteilen sollte die SSD aber noch zu 99% gut sein.


    Was mir primär Sorgen machen würde, sind die 187 Uncorrectable_Error_Cnt.

    Nach dem, was ich bislang gelesen habe, bedeutet das, dass Daten verloren gegangen sind.


    Total_LBAs_Written sollen geschriebene Sektoren sein.

    Je nach Sektorgrösse ergeben sich dann die TBW. Wobei ich nicht sicher bin, ob die logische oder physikalische Sektorgrösse ausschlaggebend ist, falls die sich unterscheiden.

    Da gibt es auch Rechner im Netz, wenn man das nicht mit der Hand machen will: https://www.virten.net/2016/12…bytes-written-calculator/

    Wobei ich auch eine SSD von Kingston habe, die da GBs anstelle von Sektoren angibt.


    Bei 512Byte Sektorgrösse komme ich auf ~22TBW. Das ist schon einiges in der Zeit, aber weit weg von den garantierten 1200.

    Wobei die Angabe 512Byte Sektorgrösse physikalisch eigentlich nicht stimmen kann (ist aber auch bei mir so).

    Aber selbst mit 4k Sektoren liegt man mit 175TBW noch im grünen Bereich.


    Ich lasse bei der Partitionierung meiner SSDs etwa 5% unpartitioniert (Reserve), damit einige schlechte Blocks Reserve sind.

    Trim ersetzt das nicht. Auch wenn man 30% frei lässt.

    Das habe ich probier, sogar mehrfach :computertod .


    Die SSD wurde doch mit discard gemountet oder anderweitig getrimmt?


    Eventuell ist auch das .vdi-Image problematisch.

    Auch da sollte das alignment stimmen und getrimmt werden.

    Ich verwende zwar auch Virtualbox, aber mit deutlich kleineren Images und das auch nur gelegentlich. Ausserdem sind meine Images variabel, es gibt also keine unbenutzten Stellen darin. Das Thema habe ich hier deshalb bislang grosszügig ignoriert.

    Gruss
    SHF


  • Eine ältere 860 EVO:

    Die 15 oder 115 sind RAW, offenbar die Zahl der Vorgänge.

    An sich auch bei der 840er nichts Auffälliges zu sehen.


    Interessant wäre auch smartctl -x, u.a. der "Percentage Used Endurance Indicator"-Wert dabei.

    Bei dieser Samsung noch "0", aber bei der VDR-SSD

    Wenn die/der "stirbt", wartet schon eine neue SSD und 22.04 zur Installation.

  • Den RAW-Wert kann man hier wohl vergessen.

    115 machen für mich als Prozent-Wert keinen Sinn.

    Natürlich macht das Sinn, zeigen meine beiden SSDs bei welchen TBW innerhalb 3 Monaten mal überrannt wurden auch, 102% resp. 111% ... 😉


    Der TBW Wert ist hart codiert und die realen TBW liegen ja auch vor, also ein einfacher Dreisatz ... Deine SSD kann es sehr wohl 15% über festgelegtem TBW liegen ...

    HowTo: APT pinning

    Edited once, last by fnu ().

  • SMART attribute 177 (Wear Leveling Count)

    This attribute represents the number of media program and erase operations (the number of times a block has been erased). This value is directly related to the lifetime of the SSD. The raw value of this attribute shows the total count of P/E Cycles.

    Der RAW-Wert von Wear_Leveling_Count von Samsung SSDs sagt also nicht viel aus.

    VALUE gibt an wie viel Prozent noch gut sind.


    Das blöde bei SMART ist, dass jeder Hersteller da sein Ding zu machen scheint. Ein sinnvolles Auswerten erleichtert das nicht gerade.

    Gruss
    SHF


  • gibt an wie viel Prozent noch gut sind.

    Im Fall der SSD von Dr. Seltsam würde das bedeuten 12% sind noch gut?

    HowTo: APT pinning

  • 12 sind RAW_VALUE.

    Das soll angeben wie oft eine Flash-Zelle schon überschrieben wurde. (Im Durchschnitt, nehme ich an.)

    Wenn man etwas such findet man Werte über 300, 400 ...

    Da man nicht weiss wie viel da "schlecht" ist, hilft der Wert auch nicht wirklich.


    VALUE ist 99.

    Der Wert soll von 100 runter zählen.

    Die SSD sollte laut dem Wert also noch zu 99% gut sein. Also 1% verbraucht, praktisch neu.


    Nach meiner Meinung gilt das für alle Werte von Dr. Seltsams SSD, die auf Verschleiß hindeuten würden.

    Datenfehler sind aber definitiv vorhanden.


    Für mich gibt es da nur 2 sinnvoller Erklärungen:

    1.: Hardwaredefekt.

    2.: TRIM hat nicht funktioniert.


    Wenn man letzteres ausschliessen kann, ist es IMHO definitiv ein Garantiefall und sollte problemlos anerkannt werden.

    Gruss
    SHF


  • Ich habe die SSD damals eingebaut, Ubuntu installiert und mich darauf verlassen, dass das Betriebssystem alle Einstellungen korrekt vornimmt. Weder habe ich eine discard Option manuell in der fstab ergänzt noch sonstwie einen TRIM Mechanismus eingerichtet. Ich meine mich zu erinnern, dass ich dazu vorher recherchiert hatte und das Ergebnis war, dass man bei modernen SSDs und aktuellem Ubuntu sich um nichts mehr kümmern braucht, sondern eine SSD wie eine normale HDD einbauen kann.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • SHF Mit Verlaub was soll das mit dem "RAW_VALUE"? Das ist ein Counter, welcher offensichtlich von 99 dezimal runterzählt ... was auch immer die kalkulatorische Grundlage dafür ist.


    Und dann das ewige TRIM, TRIM ... TRIM verhindert nur unnötige "write IOs" auf die SSDs, und das funktioniert seit Jahren problemlos unter Linux, egal welche einigermaßen aktuelle Distro. Wie lange sind SSDs nun am Markt?


    Dr. Seltsam TRIM verhindert generell nicht, das eine tatsächlich hohe Änderungsrate die kalkulierte und codierte TBW über die Zeit aufläuft. SSDs honorieren btw. auch (dauerhaft) höhere Temperaturen nicht so wirklich ...


    SSDs haben sich m.E. eigentlich als erstaunlich zuverlässig erwiesen, auch wenn Du naturgemäß gerade einem anderen Eindruck hast. Aber Hardware ist Hardware und kann kaputtgehen, immer doof wenn es einen selbst trifft. Alle SSDs die ich irgendwann mal gekauft habe laufen heute noch, teilweise 12 Jahren alt ...

    HowTo: APT pinning

  • Das ist hier auch kein SSD-Problem, sondern ein Samsung-Skandal, wie in #3 schon festgestellt wurde.

    Samsung 870 EVO - Beware, certain batches prone to failure!
    Certain 870 EVO 4TB and 2TB drives are affected by early failures where they develop uncorrectable errors and some data just cannot be read from them anymore.…
    www.techpowerup.com


    Und die Qualitätsprobleme bei Samsung sind offenbar nicht nur auf die 870 EVO beschränkt:

    News - Samsung 990 Pro: SMART-Wert „Health“ sinkt bei einigen viel zu schnell
    Mehrere Nutzer melden ein Problem mit Samsungs aktuellem SSD-Flaggschiff 990 Pro. Demnach sinkt der Zähler für die verbleibende Haltbarkeit (Health) viel…
    www.computerbase.de

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Das mit den Samsung SSDs sieht ja gar nicht gut aus....

    Und wer weiss bei welchen Herstellern die Chips noch gelandet sind.


    Bei den aktuellen Preisen wollte ich mir eigentlich eine 990er m.2 zulegen. Ich glaube, das überlege ich mir nochmal ...


    Heutige Distributionen sollten das Thema trim eigentlich auch im Griff haben, wie auch immer sie es machen.

    Ich gehe daher eher von einem Hardware-Defekt aus, besonders, weil das ein Serienfehler zu sein scheint.

    Kontrolle kann aber nie schaden. Ich persönlich bin immer gerne ganz sicher, bevor ich eine RMA stelle. Das kann im Zweifelsfall ganz schön teuer werden, wenn man es Unberechtigt macht.


    Ubuntu scheint standard-mässig auf "Batched Discard" zu setzen. Das sollte es eigentlich tun.

    (Ich persönlich verwende das nicht mehr, da bei mir mal das Skript gehangen ist, was mich wahrscheinlich eine SSD gekostet hat. Ist aber eher Geschmackssache als wirklich begründet.)

    Ich würde mal schauen, ob der Cron-Job wirklich gelaufen ist und ob er die SSD wirklich getrimmt hat. Das müsste im Logfile /var/log/batched_discard.log stehen. Mehr kann man da nicht machen.


    Mit Verlaub was soll das mit dem "RAW_VALUE"? Das ist ein Counter, welcher offensichtlich von 99 dezimal runterzählt ... was auch immer die kalkulatorische Grundlage dafür ist.

    Irgendwie habe ich das Gefühl, wir reden aneinander vorbei...

    Wear_Leveling_Count hat 2 Counter VALUE und RAW_VALUE, wie jeder SMART-Wert.

    RAW_VALUE zählt bei Samsung von 0 hoch. Ende unbekannt.

    VALUE zählt von 100 runter auf 0. Bei 0 gibt es dann eine Fehlermeldung.


    TRIM verhindert nur unnötige "write IOs" auf die SSDs, und das funktioniert seit Jahren problemlos unter Linux, egal welche einigermaßen aktuelle Distro.

    TRIM gibt unbelegte Speicherbereiche dem SSD-Controller bekannt.

    So kann er eine Datei beim schreiben umlagern, wenn der Block überdurchschnittlich oft beschrieben wurde. Das verteilt die Schreiblast auf alle freien Bereiche der SSD.

    Ohne TRIM sieht die SSD für den Controller schnell prall gefüllt aus. Er kann die Datei nicht umlagern und er muss einen Reserveblock verwenden, wenn der Block verschlissen ist.


    Normalerweise funktioniert das seit Jahren (meist) einwandfrei. Falls nicht, sind die Auswirkungen aber wie hier beschrieben. Was ich aus eigener Erfahrung berichten kann.

    Deshalb habe ich das, der Vollständigkeit, halber erwähnt.

    Gruss
    SHF


  • Firmware Version: SVT01B6Q

    Die ist veraltet und es gibt schon längst eine Neuere: https://semiconductor.samsung.…er-storage/support/tools/ -> Firmware -> SATA SSD-870 EVO Firmware

  • Das ist hier auch kein SSD-Problem, sondern ein Samsung-Skandal, wie in #3 schon festgestellt wurde.

    Ja, schon irgendwie, aber ein fehllaufender SMART Wert ist eine Sache ... Du hast ja wohl richtige Lesefehler, oder?

    HowTo: APT pinning

    Edited 2 times, last by fnu ().

  • Es gibt Dateien, die sind nicht mehr lesbar. Zum Glück nicht viele. Ärgerlich ist, dass die auch in meinem backup fehlen, weil ich die schon dort aufgetretenen errors bei der letzten Sicherung anscheinend nicht bemerkt hatte.

    Die wichtigste Datei war eigentlich die vdi-Datei von Win10. Das ist die einzige, die zu meinem Erstaunen nach wiederholten Versuchen irgendwann ohne Fehlermeldung doch noch kopierbar war.

    ....

    Ich versuche bislang vergeblich herauszufinden, wie man bei Samsung eine RMA-Nummer beantragt.Unter https://semiconductor.samsung.…ort/customer-service/#rma finde ich nur ein Schaubild des Prozesses, aber nirgendwo einen Link zum Eröffnen eines Falls. Nachdem ich in einigen Foren gelesen habe, dass der Support von Samsung inzwischen hundsmiserabel sein soll (wochenlange Wartezeit, bis man eine RMA-Nr. mitgeteilt bekommt, kleinliche Abwicklung, Ersatz in Form von gebrauchten SSDs) bin ich am Überlegen, ob ich mich lieber an den Händler halte, zumal ich noch innerhalb der einjährigen Gewährleistungsfrist bin. Kann der Händler dann die reklamierte SSD an Samsung schicken mit dem im Ergebnis gleichen Resultat?

    ...

    Habe gerade mal die Firmware meiner ersatzweise reaktivierten Samsung SSD 850 EVO 500GB geprüft:Firmware Version: EMT03B6Q

    Bei Samsung gibt es nur eine EMT02B6Q, und in Foren wird spekuliert, dass Samsung die Disks mit einer Beta-Firmware ausgeliefert hat, die später zurückgezogen wurde. Alles wenig vertrauenserweckend.

    ...

    Die zweite, später gekaufte 870 EVO mit aktueller Firwware stammt aus 2022.04

    Bei Samsung steht

    Quote

    *The 870 EVO model will be manufactured with a revised V6 process starting November 2022.

    Ich habe bis jetzt vergeblich versucht herauszufinden, was ein V6 process ist. Es bleibt das ungute Gefühl, dass auch dieses Exemplar die gleichen Hardwarefehler hat, die lediglich von einer dafür optimierteren Firmware umgangen werden. Ich glaube, sensible Daten werde ich dieser SSD nicht mehr anvertrauen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Übrigens läuft Samsung Magician weder unter wine noch in Virtualbox. In Virtualbox kommt gleich beim Öffnen "...has encountered an error and cannot continue".

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • aktueller Stand: Samsung hat den Linux-Support für Magician eingestellt. Es gibt nur noch ein DC Toolkit für Data Center, wobei unter dem Link eine Samsung_SSD_DC_Toolkit_for_Linux_V2.1.exe angeboten wird, die weder unter Linux noch Windows lauffähig ist.

    Bootfähige isos zum Installieren neuer Firmware gibt es, aber bezüglich aller anderen Funktionen, darunter Tests, ist die Empfehlung, vorhandene Linux-Tools zu nehmen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!