Bei SSD Trim aktivieren und prüfen?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • meute Bernd hat Dein Problem nachgestellt (20:15 in #29) und um 0:06 in #30 sein Ergebnis geschrieben. Wenn er dann um 0:26 in #31 nachfragt...

    Ehrlich gesagt, verstehe ich als Linux-Anfänger Ü50 erst jetzt, was der Test aussagt.

    Bisher hatte ich es wegen meiner heißen SSD nur überflogen.

    Zu viele Probleme auf einmal...

    ...ist das, angesichts des Aufwandes, den er betrieben hat, nicht ein "Danke" wert?

    Statt dessen, Dein #32...

    Kein Danke wert?

    Ist ein :thumbup:unter dem Post kein danke?

    Mein #32 bezog sich auf:

    wat is los??

    Erst son Aufriss... und dann?

    Geht es bei dir oder verschieappelst du dich einfach.

  • Info, nicht dass es wieder heisst, ich melde mich nicht.

    Soll jetzt KEINE Diskussion beginnen über nächstes Problem.

    Habe gestern heiße SSD wieder durch SD-Karte ersetzt.

    Gesichertes Image vom Freitag zurückgespielt.

    RPi empfängt jetzt aber über den USB-to-Seriell-Adapter keine Daten mehr von der Heizung.

    Jetzt ist vermutlich das nächste Teil defekt.

    Ich könnt langsam k.tz.n.

    Bin da aber im anderen Forum dran.

  • OT:

    Nur zur Info für alle Mitleser. Ein Problem weniger.

    Ich habe grad andere Probleme mit der SSD.

    Der RPi4B läuft damit nicht sauber.

    Die SSD wird extrem warm.

    Hier ist der Thread dazu:

    SD-Karte durch SSD ersetzt - Jetzt stellt der RPi4B jede Nacht den Betrieb ein (oder hängt sich auf?)

    Habe gestern die heiße SSD wieder durch SD-Karte ersetzt.

    Gesichertes Image vom Freitag zurückgespielt.

    RPi empfängt jetzt aber über den USB-to-Seriell-Adapter keine Daten mehr von der Heizung.

    Jetzt ist vermutlich das nächste Teil defekt.

    Habe heute meinen Prolific PL2303 USB-to-Seriell-Adapter durch einen älteren Prolific PL2303 USB-to-Seriell-Adapter von der Arbeit ersetzt.

    Und siehe da, der RPi empfängt wieder Daten von der Heizung.

    Dann hat die heiße SSD wohl den USB-to-Seriell-Adapter geschossen.

    Einmal editiert, zuletzt von meute (27. September 2020 um 12:41)

  • Hallo,

    wie hier geschieben, habe ich nun eine neue SSD inkl. aktiven USB 3.0 Hub mit Netzteil verbaut.

    Unten habe ich zusammengefasst, was ich jetzt bei der neuen SSD gemacht habe.

    Mal sehen, ob ich das mit dem Aktivieren von Trim richtig verstanden habe.

    Bash
    # Raspberry Pi neu starten:
    $ sudo reboot
    Bash
    # Prüfen, ob Trim aktiviert ist und funktioniert:
    $ sudo systemctl list-timers
    #<Bildschirmausgabe>
    NEXT                          LEFT       LAST                          PASSED      UNIT                         ACTIVATES
    Mon 2020-09-28 00:00:00 CEST  11h left   Sun 2020-09-27 12:45:37 CEST  5min ago    fstrim.timer                 fstrim.service
    #</Bildschirmausgabe>
    # Hier erfolgt Trim am Montag 28.09.2020 um 00:00:00 Uhr.
    Bash
    # Wenn die Ausführungszeit des Trim-Timer vorbei ist, kann man prüfen,
    # ob ein Laufwerk getrimmt wurde:
    journalctl -ae | grep trim
  • Mal sehen, ob ich das mit dem Aktivieren von Trim richtig verstanden habe.

    Aber Vorsicht: Es gibt Hersteller, die Trim fehlerhaft in die Firmware ihrer SSD implementiert haben. Bei SSDs von Crucial und Micron sollte man auf Trim grundsätzlich verzichten, denn Firmware-Bugs bei einigen Modellen können bei Trim und gleichzeitigen Schreibvorgängen zu Datenverlust führen. Neuere Kernel-Versionen haben sogar eine schwarze Liste, um Trim auf diesen Modellen ganz zu verbieten.


    Ein sofortiges Trim (Online Discard) über den Parameter „discard“ in den Mount-Optionen der Datei „/etc/fstab“ ist inzwischen nicht mehr empfehlenswert, da das bei einigen SSDs zu Leistungsnachteilen führt. Aktuelle Distributionen sehen von diesem Parameter sowieso ab.

  • meute Du weisst aber nicht ob Windows nicht auch eine Blacklist hat, mit der dann bestimmte Hersteller oder Plattenserien dann wieder vom trimmen ausgenommen sind. Denn wenn es solche bekannten Bugs gibt und Microsoft da nicht drauf reagiert, gibt's Schlagzeilen wie „Windows macht SSDs kaputt“, die sich Microsoft sicher nicht leisten möchte.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • Bash
    # Wenn die Ausführungszeit des Trim-Timer vorbei ist, kann man prüfen,
    # ob ein Laufwerk getrimmt wurde:
    journalctl -ae | grep trim

    Ich werde nächste Woche berichten, was dieser Befehl ausgibt.

    Der fstrim.timer läuft immer Mo. um 0:00 Uhr.

    Diesen Montag hat er nichts ausgegeben.

    Am Mo, um 0:17 Uhr hat nämlich der RPi wieder den Betrieb eingestellt.

    Aber für dieses Problem scheine ich endlich die Ursache (fail2ban) gefunden zu haben.

  • Und hier

    bernd@schleppi:~$ journalctl -ae | grep fstrim

    Sep 21 00:00:29 schleppi fstrim[8927]: /: 156,7 GiB (168280363008 bytes) trimmed on /dev/sda1

    Sep 21 00:00:29 schleppi systemd[1]: fstrim.service: Succeeded.

    bernd@schleppi:~$

    Bei mir sollte heute um 0 Uhr der Trim-timer zugeschlagen haben:

    Aber leider erhalte ich kein Ergebnis:

    $ journalctl -ae | grep fstrim

  • Moin meute,

    dann schau mal wann dein journal neu angelegt wurde. Siehst du in der ersten Zeile nach Eingabe von : journalctl.

    Obwohl die Aussage nicht richtig ist. Der RPI hat ja keine eingebaute Uhr.

    Sonst schau mal mit cat /var/log/syslog | grep fstrim. Falls da auch schon eine neue Datei angelegt wurde, dann mit cat /var/log/syslog.1 | grep fstrim.

    Str, aber ich kann es nicht genauer sagen. Bei meinem Debian gibt es keine alten journald-Dateien und auf einem RPI habe ich kein fstrim aktiv. Macht bei Sd-Karten auch keinen Sinn.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Sonst schau mal mit cat /var/log/syslog | grep fstrim. Falls da auch schon eine neue Datei angelegt wurde, dann mit cat /var/log/syslog.1 | grep fstrim.

    Leider kein Ergebnis: cat /var/log/syslog.1 | grep fstrim

    less /var/log/syslog.1 geht zurück bis Oct 5 00:00:31.

    Was passiert denn laut Deiner < man fstrim> mit der Fehlermeldung, wenn Deine SSD fstrim/discard nicht ausführen kann ?

    Das passiert:

    Code
    $ sudo fstrim -v /
    fstrim: /: the discard operation is not supported

    Hier hat Jürgen Böhm auf die Seite verwiesen:

    https://www.jeffgeerling.com/blog/2020/enab…on-raspberry-pi

    Dann lsblk -D laut der Seite:

    https://www.jeffgeerling.com/blog/2020/enab…on-raspberry-pi

    sda und sdb ist jeweils eine SSD.

    sda = Boot und Root (Ersatz für SD-Karte)

    sdb = Für Datensicherung

    Code
    $ lsblk -D
    NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
    sda                0        0B       0B         0
    ├─sda1             0        0B       0B         0
    └─sda2             0        0B       0B         0
    sdb                0        0B       0B         0
    └─sdb1             0        0B       0B         0
    mmcblk0            0        4M   455,4G         0
    └─mmcblk0p1  3145728        4M   455,4G         0

    Dann sudo sg_vpd -p bl /dev/sda und sudo sg_vpd -p bl /dev/sdb laut der Seite:

    https://www.jeffgeerling.com/blog/2020/enab…on-raspberry-pi

    Dann sudo sg_vpd -p lbpv /dev/sda und sudo sg_vpd -p lbpv /dev/sdb laut der Seite:

    https://www.jeffgeerling.com/blog/2020/enab…on-raspberry-pi

    Info laut der Seite:

    https://www.jeffgeerling.com/blog/2020/enab…on-raspberry-pi

    ==========

    If the Maximum unmap LBA count is greater than 0, and Unmap command supported (LBPU) is 1, then the device firmware likely supports TRIM.

    ==========

    Beides ist bei mir der Fall.

    Also müsste die SSD Trim unterstützen.

    Oder Trim ist noch nicht nötig, weil die SSD erst 2 Wochen läuft?

    Aber passt die Vermutung dann zu der Meldung von oben?:

    Code
    $ sudo fstrim -v /
    fstrim: /: the discard operation is not supported
  • Moin meute,

    ok, dann muss ich wieder einiges wissen..

    Rennt der RPi 24/7 ?

    Bekommt er via Netzwerk die Uhrzeit?

    Ist deine SD-Karte schreibgeschützt?

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Und warum willst Du das absolut nicht wahrhaben : "fstrim: /: the discard operation is not supported"

    Das ist schon seit #20 und mehr als 2 Wochen bekannt. (wenn / die root Partition auf der SSD ist).

    Weil das jetzt eine andere, neue 2,5"-SSD ist als in #20.

    Rennt der RPi 24/7 ?

    Bekommt er via Netzwerk die Uhrzeit?

    Ist deine SD-Karte schreibgeschützt?

    Ja, RPi läuft 24/7.

    Als ich den RPi damals eingerichtet habe, wurde NTP konfiguriert.

    SD-Karte steckt im RPi mit einer leeren FAT32-Partition. Ist aber nicht gemountet.

    Gruß

    meute

  • Weil das jetzt eine andere, neue 2,5"-SSD ist als in #20.

    Und die ist trimmfähig ?

    Woher weisst Du das ?

    Funktioniert fstrim, wenn Du die SSD (ohne USB) direkt an einen SATA Kontroller (am PC) anschliesst ?

    Wenn fstrim in seiner Service-Unit kommentarlos (also auch ohne Fehlermeldung) fstrim nicht ausführt:

    Ist die SSD nicht trimmfähig, oder

    wird der Trimmbefehl vom USB -> SATA Kontroller nicht unterstützt.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Moin meute,

    in dem Beitrag #20 schreibst du folgendes:

    Bei mir:
    Code
    $ sudo fstrim -v /
    fstrim: /: the discard operation is not supported

    Wir reden aber noch von der gleichen SSD?

    Weil, wenn das immer noch so ist dann ist es halt so.

    RTFM hat da ja schon drauf hin gewiesen.

    Dann habe ich mal ein wenig gelesen.

    Die Option discard in /etc/fstab ist eine Art "onlinefreigeben". Es kann zu Performanceeinbrüchen kommen. Weil immer versucht wird Blöcke frei zugeben.

    Die Nutzung von fstrim durch die Serviceunit fstrim.timer geht einen anderen Weg.

    Zumindest sind beide Massnahmen gleichzeitig kontraproduktiv!!


    Nun stellt sich also die Frage, ob deine Geräte fstrim unterstützen.

    Was sagt denn sudo fstrim -v /dev/<ssd> ? <ssd> bitte durch Partition ersetzen.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!