[Erledigt] TP T450s - kein fstrim möglich?

[kalle123]

Stehe momentan vor einem (für mich) Rätsel.
Es wird augenscheinlich kein 'fstrim' ausgeführt, obwohl ..

Code: Alles auswählen

~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Mon 2019-09-16 11:33:02 CEST; 9min ago
  Trigger: Mon 2019-09-23 00:00:00 CEST; 6 days left
     Docs: man:fstrim

Sep 16 11:33:02 T450s systemd[1]: Started Discard unused blocks once a week.

Code: Alles auswählen

~$ systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Ein Blick ins journal liefert mir das hier

Code: Alles auswählen

~$ journalctl | grep fstrim
.
Sep 16 11:49:54 T450s systemd[1]: fstrim.timer: Succeeded.
Sep 16 11:59:19 T450s systemd[1]: fstrim.timer: Succeeded.
Sep 16 12:36:31 T450s systemd[1]: fstrim.timer: Succeeded.
Sep 16 13:00:51 T450s systemd[1]: fstrim.timer: Succeeded.

Nur ein

Code: Alles auswählen

... fstrim.service: Succeeded

taucht nun seit Wochen nicht auf.

Ich habe die Vermutung, das es an der SSD liegen könnte

Code: Alles auswählen

~$ inxi -D
Drives:
  Local Storage: total: 223.57 GiB used: 27.02 GiB (12.1%) 
  ID-1: /dev/sda vendor: Intel model: SSDSC2BF240A5L size: 223.57 GiB 

Hier https://git.kernel.org/pub/scm/linux/ke ... re.c#n4522
taucht etwas zu +INTEL + SSD auf.

Kann mir hier bitte jemand meine Vermutung verifizieren? Und was bedeutet das jetzt, andere SSD?

Gruß KH

[jph]

Was sagt die Service-Unit? Das muss in etwa so aussehen:

Code: Alles auswählen

jan@proliant:~$ journalctl -u fstrim.service -b 0
-- Logs begin at Sun 2017-11-12 20:57:57 CET, end at Tue 2019-09-17 20:05:56 CES
Sep 09 00:00:15 proliant systemd[1]: Starting Discard unused blocks...
Sep 09 00:02:56 proliant fstrim[19840]: /: 112,6 GiB (120934653952 bytes) trimme
Sep 09 00:02:56 proliant systemd[1]: fstrim.service: Succeeded.
Sep 09 00:02:56 proliant systemd[1]: Started Discard unused blocks.
Sep 16 00:00:06 proliant systemd[1]: Starting Discard unused blocks...
Sep 16 00:01:15 proliant fstrim[63277]: /: 110,9 GiB (119029096448 bytes) trimme
Sep 16 00:01:15 proliant systemd[1]: fstrim.service: Succeeded.
Sep 16 00:01:15 proliant systemd[1]: Started Discard unused blocks.

journald loggt im Default flüchtig. Sofern du nicht auf persistentes Logging umgestellt hast (man 5 journald.conf, Option Storage), gehen dir die Logeinträge beim Reboot verloren. Möglicherweise siehst du sie deswegen nicht. Das Beispiel von oben stammt von meinem Heimserver, der loggt persistent. (Tipp: mit -u kannst du in journalctl eine Unit gezielt abfragen und musst nicht mit grep herumturnen. Mit -b 0 filtere ich auf Logeinträge seit dem letzten Reboot.)

Ob fstrim bzw. die Service-Unit grundsätzlich funktionieren, kannst du mit

Code: Alles auswählen

# systemctl start fstrim.timer

testen.

[kalle123]

Dank dir erst mal für die Antwort

Journal ist bei mir grundsätzlich 'persistent'. Also '/var/log/journal' ist angelegt.

Ob fstrim bzw. die Service-Unit grundsätzlich funktionieren, kannst du mit testen.

Siehe dazu den Eintrag in #1 oben

Code: Alles auswählen

~$ systemctl status fstrim.timer

loaded und active!!

Die Abfrage nach 'fstrim.service' liefert NULL. Der timer läuft, aber es wird einfach kein 'fstrim.service' ausgeführt.

Auch ein händisches

Code: Alles auswählen

~$ sudo fstrim -av

bringt nichts. Der Befehl hängt einfach. Keine Meldung, einfach nix.

Für deine Tipps zu journalctl Werd mir das ins 'schlaue Buch' notieren.

Bin heute hierauf gestossen

https://wiki.archlinux.org/index.php/Le ... _T450s#SSD

fstrim sollte also beim T450s gehen.

Hab den selben SATA Kontroller wie in der Archlinux Seite drin.

kalle@T450s:~$ lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #6 (rev e3)
00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
>>>>
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03) <<<<
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03)
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

Ich habe die Intel SSD stark in Verdacht (die wird ja auch in der o.a. blacklist der kernel.org erwähnt!)

WARNING

Some firmware versions on some SSD models have bugs that result in data corruption when used in certain ways. For this reason the Linux ata driver maintains a "blacklist" of certain things it shouldn't do on certain drive/firmware combinations. This list is in the linux source at drivers/ata/libata-core.c. If you have a blacklisted controller/drive combination, you are at risk until a newer kernel avoids the problem.

In particular, many drives, including Samsung, Micron, Crucial have problems with discard/TRIM. Also see 790520

Quelle: https://wiki.debian.org/SSDOptimization#WARNING


Ne Ersatz SSD ist unterwegs und ich werde die Platte wechseln! Ich will es jetzt wissen

Bei den beiden anderen Rechnern hier (DEBIAN + SSD) läuft die 'fstrim' Sache ohne Probleme.

Grüße KH

[hikaru]

Ich habe die Intel SSD stark in Verdacht (die wird ja auch in der o.a. blacklist der kernel.org erwähnt!)

Das war auch mein erster Verdacht und ich hätte dir das auch mitgeteilt. Aber deine SSD ist doch gar nicht geblacklistet.

Du hast:
SSDSC2BF240A5L

Kernel-Blacklist:
INTEL*SSDSC2MH*

[kalle123]

Hab ich auch gesehen. Nur wie weit ist die 'blacklist' aktuell und wird geplegt?

Aber der SATA Kontroller wird ja so auch im Archlinux Wiki gelistet und scheidet wohl aus. Bleibt eigentlich nur die Platte übrig.

Lässt mir keine Ruhe Ich werde berichten.

cu KH

[kalle123]

SSD ist gewechselt. Kam ne WD SSD rein.
DEBIAN aufgespielt, erster Befehl

fstrim -av

und es wird getrimmt. War also die INTEL SSD, die nicht wollte oder konnte.

Gruß KH