SMART-Werte: Ab wann sollte man ein Auge drauf werfen

  • In meinem VDR Werkelt eine Samsung 2,5" SSD und eine Normale 3 TB Festplatte für die Aufnahmen. Mir ist jetzt aufgefallen, das der Wert Wear Leveling immer niedriger wird. Hier mal die Werte von Heute und vor einem Jahr:

    Muss ich das im Auge behalten?

    Kanallogos: Picon.cz2VDR | Picons2VDR | MP-Logos
    Backupskripte:
    MV_Backup (RSync) | MV_BorgBackup (Borg)

    Skin: Skin FlatPlus  VDR-Add_MSGT

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde."
    [Ken Olson], Präsident der Digital Equipment Corp., 1977

    VDR01 - yaVDR 0.7 (VDR 2.7.3)

    VDR 2.7.3; Gehäuse: Antec Fusion V2 Black & iMon LCD; Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, GTX 1050 Ti, 8 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5

    >Systeminfo.txt< [VDR-User #1540]

  • Das ist ein Prozentwert für die zu erwartende verbleibende Lebenserwartung der Platte, d.h. der Wert ist von 63% auf 57% gesunken.

    Meine 128GB Samsung 830 war nach 13 Jahren VDR auf 80% runter.

    Ich persönlich würde die einfach mal vorsorglich tauschen, SSD-Preise sind ja kein Weltuntergang mehr.

  • Bei mir sind es also 6% pro Jahr.

    Nach 13 Jahren wäre ich rechnerisch auf 22%. Also scheint mein VDR die Platte deutlich stärker zu belasten...

    Kann man da eventuell was drehen? (Log, EPG-Bilder, Datenbank)

    Kanallogos: Picon.cz2VDR | Picons2VDR | MP-Logos
    Backupskripte:
    MV_Backup (RSync) | MV_BorgBackup (Borg)

    Skin: Skin FlatPlus  VDR-Add_MSGT

    "Es gibt keinen Grund, warum irgendjemand einen Computer in seinem Haus wollen würde."
    [Ken Olson], Präsident der Digital Equipment Corp., 1977

    VDR01 - yaVDR 0.7 (VDR 2.7.3)

    VDR 2.7.3; Gehäuse: Antec Fusion V2 Black & iMon LCD; Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, GTX 1050 Ti, 8 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5

    >Systeminfo.txt< [VDR-User #1540]

  • Das oben ist meine VDR SSD. Alle Zeilen die ich geloescht habe waren 0. Hatte ich 2020 gekauft nachdem meine SanDisk SSD von 2019 nach einem Jahr auf read-only gegangen ist. Und zurueckschicken wollte ich die auch nicht, weil da viel privates Zeugs unverschluesselt drauf war - und ich die gar nicht mehr geloescht bekommen habe. Also dachte ich vertraue ich mal WD...

    Sieht jetzt vom Media_Wearout_Indicator so aus, als ob das Teil bei 26% seiner Lebensdauer angekommen ist, wenn ich den Beschreibungen von "Media_Wearout_Indicator" gegoogled vom Internet und chatgpt glauben schenke... Was man lieber nicht tut...

    Das ist die zweite Platte, die ich auch 2020 gekauft habe, und die als Ersatz unbenutzt immer mitlaeuft im VDR. Allerdings 2.5 Faktor statt M.2 (hatte beim Kauf nicht genau gewusst, was ich brauchte, also mal beide Modelle gekauft).

    Analyse:

    Wenn ich mal davon ausgehe, das die Bedeutung von Media_Wearout_Indicator bei beiden Modell dieselbe ist, dann ist das am ehesten noch ein Prozentwert der bei einer frischen Platte bei 0 anfaengt. Meine Betriebsplatte ist bei 26% nach 181 TB geschrieben auf TLC. Laut Geizhals soll die 400TB machen, wenn man die Prozentzahl hochrechnet sollten es eher 690TB sein. Mal abwarten...

    Die "Total Bad Blocks" sind wohl wirklich von Fabrik, aber keine "grown", also irelevant.

    Hatte seinerzeit auch deswegen WD gekauft, weil die eben genau die NAN_GB_Written_TLC variable hatten, damit die Diagnose einfacher ist.

    Ich mache auf der Platte einmal in der Woche ein trim:

    Code: crontab
    0                                  3 * *  0 /sbin/fstrim -va

    Hatte mal mit meiner normalen rate an (ueberfluessigen, aber man hats ja gerne aufgenommen ;) VDR Aufnahmen ausgerechnet, das die Platte 10 Jahre halten sollte ;-)) Jetzt ist ja noch alles nur noch HD ab Januar... ;-))

    Ich glaube ich hatte bei der ersten SSD von 2019 mit "discard" gemountet, statt wie hier so bloss selten trim zu machen. Evtl. hat das zu deren Tod beigetragen.

    Wie man da nun den "Wear_Leveling_Count" vom OP interpretieren soll - keine Ahnung. Bloss einfach dem Internet glauben scheint mir bei dieser "super dokumentierten" SMART Technologie problematisch zu sein. Auf jeden Fall mal bei Geizhals gucken, was die Lebenserwartung der Platte sein soll (wenn dokumentiert), und dann mit Blockgroesse und LBA count vergleichen.

  • Meine Samsung 850 sagt nachdem ich ganze linux system (Linux from Scratch plus BLFS) in den letzten Jahren mehrfach darauf kompiliert habe

    Code
    177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Der wear level reflektiert den vom Hersteller dieses SSD Modells zugewiesenen Wert TBW (total bytes written). Entgegen der landläufigen Meinung fließen hier keine weiteren Parameter ein.

    Wenn dieser erreicht wird, heißt das nicht das die SSD zwangsläufig aussteigt, heißt erstmal nur TBW Grenze erreicht bzw. überschritten. Sollte das vor Ablauf der Consumer Garantie sein, erlischt damit die Garantie der SSD automatisch, bei allen Herstellern. Daher achte ich beim Kauf von SSDs immer auch auf den TBW, der ist vorrangig bei preiswerten Modellen auch heute noch oft erschreckend niedrig.

    Bei einer Systemplatte werden weniger Daten geschrieben als die meisten annehmen. Beim VDR als Videodisk werden sicher generell höhere Schreibraten erreicht, Aufnahmen, Schneiden, Löschen, wieder Beschreiben. Als Cache in einem NAS werden SSDs quasi gefressen. Habe/hatte aber auch zwei inzwischen ziemliche alte Intel NVMe SSDs, deren TBW in einer NAS Box innerhalb 3 Monaten aufgebraucht waren. Beide laufen/liefen bis TBW -10%, hat sie aber eh nur noch zu Testzwecken verwendet, eine hat sich inzwischen dann tatsächlich richtig verabschiedet gehabt, woraufhin ich beide entsorgt hatte. Intels TBW Einschätzung für diese Modelle hatte damit gerademal 10% Puffer.

    Der zugehörige TBW ist aber oft nicht einfach rauszubekommen, aber Geizhals listet z.B. den TBW recht zuverlässig und sorgfältig gepflegt auf.

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

  • Dann bin ich ja mal gespannt, wenn meine Samsung aussteigt:

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

  • Kann man da eventuell was drehen?

    Bei ext4 mounte ich SSDs immer zusätzlich mit:

    noatime,commit=600,discard

    und hatte bislang keine Probleme.

    Die anderen Trim-Lösungen hatten bei mir schon mal versagt und die SSD war tot, bevor mir das aufgefallen war! Seitdem SSDs nur noch mit discard.

    Das der Wear_Leveling_Count abnimmt, ist völlig normal, das tut er bei allen meiner SSDs auch, wenn auch nicht ganz so schnell, wie beschrieben.

    Ich würde erst handeln, wenn der wirklich runter ist. 57% bedeuten, dass die SSD mindestens nochmal solange halten soll.

    Panik ist eigentlich erst angesagt, wenn Reallocated_Sector, Used_Rsvd_Blk_Cnt oder dergleichen abfallen. Dann fängt der Controller an Ersatzblöcke zu verwenden, weil die Ursprünglichen Probleme machen. Ab dem Punkt kann es bei entsprechender Schreibleistung aber schnell gehen...

    Oder natürlich irgend eine anderer Wert, der auf akute Fehler hindeutet, aber da ist momentan ja alles bei 100.

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

  • kfb77 Wenn Deine Platte 512 Byte Sektorgröße hat, dann sind das laut total_LBA_written ja wohl 330 TerraByte. Was fuer ein Modell ist das denn, mal beim Geizhals geguckt, was da angegeben ist ?

    Wenn da so wie bei @MegaVOlt der Wear_Leveling_Count von 100 (frische Platte) runterzaehlt, dann sollte Deine Platte ja schon tod sein. Was oder wie dann aber das RAW_VALUE sagen soll... keine Ahnung.

    SHF Siehe oben. In meiner Erfahrung, und dem was man so auf dem Internet findet scheint es besser fuer die Lebensdauer der SSD zu sein, wenn man fstrim nur z.b. woechentlich auf der Platte macht. Gerade wenn man z.b. so wie ich ein gentoo hat und da gerne mal das ganze OS wieder neu compiliert wuerde man bei "discard" mount option dauernd viele kleine bloecke trimmen und damit die controller-logic quaelen - und im schlimmsten fall irgendwelche Bloecke immer wieder benutzen.

    Vielleicht macht das alles bei guter SSD Firmware am Ende keinen Unterschied...

  • Kommt hin, die ist mit 300TB angeben. Ist ja auch schon über 5 Jahre im 7/24 Betrieb.

    https://geizhals.de/samsung-ssd-86…b-a1756904.html

    Was oder wie dann aber das RAW_VALUE sagen soll... keine Ahnung.

    Ist Samsung intern, von Bedeutung ist nur der % Wert.

    dann sollte Deine Platte ja schon tod sein

    Das ist ja nur der garantierte Wert. Die kann heute noch kaputt gehen, oder noch Jahre laufen. Ich werde es sehen ...

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

  • In meiner Erfahrung, und dem was man so auf dem Internet findet scheint es besser fuer die Lebensdauer der SSD zu sein, wenn man fstrim nur z.b. woechentlich auf der Platte macht.

    Das hatte ich auch gelesen und es deshalb anfangs so gemacht.

    Bis das Skript wegen eines blöden Fehlers der durch ein Update rein kam nicht mehr lief und meine SSD nach 3 Monaten platt war.

    Seitdem mache ich den Zirkus nicht mehr mit und verwende discard. Soll sich doch der Kernel darum kümmern ...

    Meine SSDs fühlen sich damit anscheinend auch recht wohl, seit der Umstellung hatte ich auch keine Ausfälle mehr. Irgendwelche negativen Auswirkungen auf die Performance konnte ich zumindest nicht feststellen.

    Dein Ausfall IMHO also definitiv nichts mit der Verwendung discard zu tun.

    wuerde man bei "discard" mount option dauernd viele kleine bloecke trimmen und damit die controller-logic quaelen - und im schlimmsten fall irgendwelche Bloecke immer wieder benutzen.

    Trim teilt dem Controller doch eigentlich nur mit, ob der Block verwendet wird, oder nicht.

    Der Controller wird beim Trim-Commando also erstmal nicht viel mehr machen als den getrimmten Block in die Liste mit unbenutzten Blöcken aufzunehmen.

    Und man trimmt doch gerade darum, damit der Controller möglichst viel Auswahl an Blöcken hat um die Schreiblast bestmöglich zu verteilen.

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

  • .. was darf man von dieser SSD noch erwarten?

    Trashcan :coolgr ?

    Grusz

    Lascala LC17 - tribute to viking ;o) + atric IR / SoC ASUS J3455M-E / OctopusNet S4 / yavdr ubuntu noble / output: osd2web + kivy-osd2web / branch 'python3' via 6.4" TFT & sat>ip DVB-S/S2 via FullHD / NVidia GT1030 passiv

  • Nein. Kann noch jahrelang halten (nix "Pre-fail" nahe Limit). Oder, wie jedes Elektronikteil, morgen den "magic smoke" rauslassen z.B. wegen eines kaputten Kondensators.

    Sagt "smartctl --all ..." mehr?

    vdr User #2022 - hdvdr2:

    Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 32 GB Ram, zram-swap/tmp, ubuntu-focal+ESM, softhddevice-cuvid, ffmpeg-6.1(git)

    ddbridge-6.5 mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF1050Ti SFF (nvidia-dkms-565.77), System SSD btrfs,

    timeshift-btrfs, Video 8TB HDD XFS/cow, yavdr-ansible-2.7.3-seahawk, epgd-git mit plugins, Kernel 6.12.10+dddvb-0.9.39-git

    vdradmin-am-3.6.13-git, vdr-live-ng, vdrmanager (Smartphones als FB)

  • Der Controller meint, die SSD lebt nochmal so lange Media_Wearout_Indicator 55.

    Ich würde aber Reallocated_Sector_Ct und Available_Reservd_Space im Auge behalten. Wenn die Auf 0 sind, sind Fehler zu erwarten.

    Die beiden Werte können durch einen Fehler im Flash durchaus mal sprunghaft etwas abfallen, das ist bei den Speichergrößen möglich.

    Wenn sie kontinuierlich sinken, würde ich mir aber mal die Partitionen ansehen.

    Bei fehlendem trim zB. sterben die SSDs am Ende an fehlenden Ersatzsektoren.

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

Participate now!

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