SSD Haltbarkeit - Habe ich einfach Pech?

20er LTS. Bei beiden.
Smartwerte kann ich leider wie gesagt noch nicht posten, will ich aber unbedingt.
Mir fehlt es einfach an Gerätschaften gerade...
Habe nur den Raspberry Pi Zero W mit ein paar USB Sticks.
Status Quo ist ich habe das Teil mit einem Startup-Skript ausgestattet damit er das Image jetzt komplett headless auf den Stick schreiben kann, der dann direkt und nicht über einen Hub ohne extra Stromversorgung angeschlossen ist.
Ich kann so nicht arbeiten...:(
Ergänzung ()

Hallo,

ich habe einen Bootstick!
Code:
ubuntu@ubuntu:~$ sudo smartctl -A /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.11.0-27-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   000    Pre-fail  Always       -       414
  5 Reallocate_NAND_Blk_Cnt 0x0032   040   040   010    Old_age   Always       -       65
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       1655
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1343
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 Ave_Block-Erase_Count   0x0032   097   097   000    Old_age   Always       -       58
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       46
180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       22
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always       -       0
184 Error_Correction_Count  0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       183
194 Temperature_Celsius     0x0022   061   015   000    Old_age   Always       -       39 (Min/Max 0/85)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       65
197 Bogus_Current_Pend_Sect 0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       407
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       26
202 Percent_Lifetime_Remain 0x0030   097   097   001    Old_age   Offline      -       3
206 Write_Error_Rate        0x000e   100   100   000    Old_age   Always       -       0
210 Success_RAIN_Recov_Cnt  0x0032   100   100   000    Old_age   Always       -       0
246 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       4875616456
247 Host_Program_Page_Count 0x0032   100   100   000    Old_age   Always       -       84305811
248 FTL_Program_Page_Count  0x0032   100   100   000    Old_age   Always       -       274207497

Screenshot from 2021-12-16 22-23-01.png
 
Zuletzt bearbeitet:
Für eine startbare externe Backup-Platte ist es jetzt wohl zu spät, oder?

SSDs gehen kaputt, mal mehr, mal weniger.
HDDs gehen auch kaputt, aber Backups helfen bei beiden!
 
Ist wie gesagt kein "Mimimi meine Daten sind weg"-Thread. :)
Dafuer wird schon gesorgt, dass das nicht passiert.

Twostone schrieb:
Wie sieht denn die fstab in den betroffenen Systemen aus bezüglich den betroffenen Partitionen?
Code:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=19ddce0e-97ec-4d8c-bc8b-95fc92103052 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
#UUID=4F90-7097  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=140a8bf5-4908-4c05-9c89-785bcbd9677f none            swap    sw              0       0
UUID=4F90-7097    /boot/efi    vfat    defaults    0    1

Kann auch vom Livesystem aus mounten und die Dateien lesen.
Ich probiere einfach mal normal zu starten.

EDIT:

Leider immernoch.
IMG_20211216_233234.jpg

Und beim Herunterfahren aus der Live-Distribution.
IMG_20211216_233137.jpg
Ich würde eigentlich gerne einfach ein Startup-Repair durchführen.
Aber die letzten Meldungen kommen mir komisch vor.
Ich möchte eure Nacken nicht strapazieren, die Fotos tun mir Leid.
 
Zuletzt bearbeitet:
Prima. Dann starte doch mal manuell einen Trim.

Wenn die SSD noch erkannt wird und nicht read-only dürfte nichts gravierendes defekt sein. ;)


Edit: Daten korrupt, weshalb auch immer? Hatte bei SSDs bisher immer nur "ganz oder gar nicht". Den Rest hat wohl immer der interne Controller erledigt.

Teste die SSD doch mal in einem anderen Rechner.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Wasserhuhn
Code:
ubuntu@ubuntu:~$ sudo fstrim -a -v
fstrim: /mnt/boot-sav/sdb4: FITRIM ioctl failed: Input/output error
/media/ubuntu/4F90-7097: 226.9 MiB (237888512 bytes) trimmed on /dev/sdb1
/media/ubuntu/19ddce0e-97ec-4d8c-bc8b-95fc92103052: 19 GiB (20366606336 bytes) trimmed on /dev/sdb2

sdb4 ist "MiniBackup", ext4, 17GB. Die ist komplett leer, und das war sie meines Wissens nach auch schon vorher so.

Kann drauf schreiben, allerdings nur als sudo, das war meines Wissens nach vorher nicht so.

Komisch finde ich das hier, wenn ich versuche boot-repair auszufuehren:
Screenshot from 2021-12-16 22-59-31.png
Schliesslich habe ich eine entsprechende Boot Partition ja schon gehabt.
Screenshot from 2021-12-16 23-00-46.png

Ich habe da jetzt erstmal auf "Nein" gedrueckt. Ich bin da zu muede fuer um alleine so eine Entscheidung zu treffen...Irgendwie habe ich mir den Abend ganz anders vorgestellt.
Ich bin aber froh, dass es erstmal scheinbar kein Totalschaden ist.
 
Zuletzt bearbeitet:
Ich habe hier bald ca. 30 SSDs und eingebaut rumliegen, davon ist mir mal eine berüchtigte OCZ kaputt gegangen (wurde per Gewährleistung ersetzt), und eine Samsung 840 Pro innerhalb 6 Monaten, die anstandslos von Samsung getauscht wurde. In der Firma in unseren Arbeitsnotebooks und Servern gabs noch gar keinen Ausfall. Daher würde ich mal sagen, Du hast absolut hier Pech gehabt. Aber man muß sagen, ich kaufe auch nur die Markenprodukte, überwiegend Pro, und keine Billig-SSDs.
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Kleines Update.
Die Platte stirbt mir scheinbar vor der Nase weg.
Einige Dateien sind jetzt readonly.
Ich nutze das um Sachen außerhalb der Backuproutine zu retten. Und naja.
 
Bei den ganzen Error counts ist es zumindest kein Wunder, dass die SSD am sterben ist:

Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 183
Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 407
UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 26

Wenn die SSD jung genug ist und die Daten unwichtig genug sind ist das wohl ein Fall für die Garantie (5 Jahre bei Crucial).

Im Zweifel halt noch "irgendwie" ein vollständiges Backup-Image erstellen.
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Also die 85° C max temp sind hoffentlich eine Fehlinterpretation :rolleyes:
Ansonsten könnte das womöglich sowohl Fehler in der Verbindung zum Board, als auch vom Speicher selbst verursachen.

Wenn die Rahmenbedingungen stimmen würde ich eindeutig auf Pech tippen. Aber es sieht etwas verdächtig danach aus als wäre dem nicht so.
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Die Temperatur wurde von "Disks" wie im Screenshot angegeben anders ausgelesen.
Wäre aber auch eine Hausnummer.
Verbaut dadrin ist ein 200GE, und ich habe nur die iGPU. Bis auf Mainboard, RAM und Netzteil ist da nichts drin.
Das Teil frisst 20W und ist sich sauber. Damit kann leider nicht geheizt werden im Winter.

Das andere System ist vom Umfang her gleich aufgebaut gewesen. Nur halt älter, mit Intel G4400.

Mit dem Spielen habe ich schon lange lange aufgehört. Mittlerweile müssen die Dinger wenig verbrauchen und lange halten.

Schon eine Veränderung, wenn man vor fast 20 Jahren mit Bleistiften auf Widerständen gepinselt und Kühlerflächen geschliffen und poliert hat.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bigeagle
Gerade wo du die "alte" Hardware erwähnst: Hast du dir abseits der eigentlichen Geräte mal die SATA-Kabel angeschaut?

Vlt. hats ein Kabel ja mit Korrosion erwischt. Da wäre ein Austausch dann nicht verkehrt.

Ich hab hier ne alte Crucial M4 die seit 2011 ihre Dienste verrichtet. Auch andere SSDs sind mir noch nicht kaputt gegangen. Klar, Montagsgeräte gibts, aber gleich 3?
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Klar, immer. Angeblich sollen die nur für eine handvoll Steckzyklen konstruiert sein.
Die WDBlue hier ist allerdings M2.

EDIT:
Wem etwas komisch vorkam, der hatte Recht.
Das ist gar keine WD Blue, sondern eine Crucial MX500 250GB M2.

Wie ich auf das andere Modell kam... Ich glaube ich stand kurz davor die WD zu kaufen.
 
Zuletzt bearbeitet:
Mmmh, irgendwie läuft seit gestern gar nichts bei mir.
Also die Platte ist eine Crucial MX550 M2 250GB.
Die Platte ist, wie ich an der Rechnung sehe, von März 2020, nicht 2021.
Und es war B-Ware mit einem Jahr Gewährleistung. Platte war beim Kauf aber in Ordnung. Nur ausgepackt gewesen, laut Smart nur einmal gestartet und wieder eingepackt.
Naja...

Ich habe das Teil jetzt komplett formatiert. XUbuntu neu draufgemacht. Mehrere Lese- und Schreibtests laufen lassen. Die Werte haben sich nicht geändert.
Ich würde die einfach mal als OS-Platte weiterhin benutzen und nichts wichtiges draufhauen.

Was ich mich Frage:
Was erwartet mich?
Und wie ist das Teil jetzt kaputt(?) gegangen? Weil meine Erfahrung, auch vom Lesen, ist, die Dinger sind entweder ganz kaputt, oder gar nicht. Das Problem entstand im normalen, laufenden Betrieb.
Wie muss man sich das vorstellen vom Aufbau her?

Vielen Dank für eure Hilfestellungen und das Händchenhalten soweit. Das hat mir so ein bisschen den Tag versüßt gestern.
Mit den Fragen kann ich das dann auch ad acta legen.
 
Du solltest zumindest einen cronjob einrichten, der Dir mindestens einmal die Woche ein fstrim auf den Partitionen laufen lässt. Standardmäßig existiert der nicht.
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Danke, das ist echt ein guter Hinweis!
Ich wusste das gar nicht. Ich dachte Betriebssysteme machen das automatisch nach gutdüngen.

Wie nötig war das bei mir (hatte wohl nichts mit dem Problem zu tun, nehme ich an) anhand des Outputs, den ich gestern gezeigt habe?
 
Kann man schlecht sagen, wenn man den Füllgrad der Partitionen nicht kennt. Aber viel war's nicht, was freigegeben wurde.

Nein, es gibt zwar die Möglichkeit, per discard-mountoption nicht mehr benötigte Register als frei an den Controller zurück zu melden, das funktioniert aber vor Allem bei älteren SSDs nicht immer zuverlässig. Die sicherste Variante ist eben ein cronjob.
 
Wasserhuhn schrieb:
Stromverbrauch in der 20W Region gesamt, weil ich ein Stromgeizer bin. Keine Wärmeprobleme.
Den geringen Stromverbrauch hast Du hier im Thread 2x erwähnt. Ist dahingehend etwas zu sehr "optimiert" worden und deshalb eine mögliche Ursache für das SSD-Sterben?
 
  • Gefällt mir
Reaktionen: Wasserhuhn
Nö, gar nicht. Ist mir auch zu kompliziert geworden. Früher zu 775er Zeiten war das alles noch einfach.
 
Zurück
Oben