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
Die SMART Values Deiner Samsung SSD sind, naja, wenig hilfreich.
Das sind aber die bei Samsung üblichen.
Die liefert meine 840er auch:
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 24609
12 Power_Cycle_Count 0x0032 095 095 000 Old_age Always - 4672
177 Wear_Leveling_Count 0x0013 096 096 000 Pre-fail Always - 115
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 077 063 000 Old_age Always - 23
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 253 253 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 225
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 12101479426Ich 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 
.
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.
Eine ältere 860 EVO:
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 5080
12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 2578
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 15
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 072 050 000 Old_age Always - 28
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 211
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 27058608408Die 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
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate -O-R-- 100 100 000 - 0
2 Throughput_Performance P-S--- 100 100 050 - 0
3 Spin_Up_Time POS--- 100 100 050 - 0
5 Reallocated_Sector_Ct PO--C- 100 100 050 - 0
7 Unknown_SSD_Attribute PO-R-- 100 100 050 - 0
8 Unknown_SSD_Attribute P-S--- 100 100 050 - 0
9 Power_On_Hours -O--C- 100 100 000 - 31547
10 Unknown_SSD_Attribute PO--C- 100 100 050 - 0
12 Power_Cycle_Count -O--C- 100 100 000 - 3205
167 SSD_Protect_Mode -O---K 100 100 000 - 0
168 SATA_PHY_Error_Count -O--C- 100 100 000 - 2
169 Bad_Block_Count PO--C- 100 100 010 - 100
170 Unknown_Attribute PO--C- 100 100 010 - 0
173 Erase_Count -O--C- 041 041 000 - 0
175 Program_Fail_Count_Chip PO--C- 100 100 010 - 0
192 Power-Off_Retract_Count -O--C- 100 100 000 - 324
194 Temperature_Celsius -O---K 069 063 000 - 31 (Min/Max 12/37)
197 Current_Pending_Sector -O--C- 100 100 000 - 0
240 Unknown_SSD_Attribute PO--C- 100 100 050 - 0
....
0x07 ===== = = === == Solid State Device Statistics (rev 1) ==
0x07 0x008 1 159 N-- Percentage Used Endurance IndicatorWenn 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 ...
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.
gibt an wie viel Prozent noch gut sind.
Im Fall der SSD von Dr. Seltsam würde das bedeuten 12% sind noch gut?
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.
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 ...
Das ist hier auch kein SSD-Problem, sondern ein Samsung-Skandal, wie in #3 schon festgestellt wurde.
Und die Qualitätsprobleme bei Samsung sind offenbar nicht nur auf die 870 EVO beschränkt:
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.
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?
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
