Externe SSDs und TRIM – Wie handhabt ihr das?

Hallo, ich habe eine Frage dazu, wie ihr mit externen SSDs und dem Thema TRIM umgeht.

Hintergrund:
Ich nutze sowohl privat als auch für Freunde mehrere externe Samsung SSDs (T3 bis T9 mit USB-C Anschluss). Diese hängen entweder direkt an PCs, laufen als NAS-Speicher an einer Fritzbox oder an einem Pi4. Die SSDs sind mit ext4 oder NTFS formatiert.

Das Problem:
Laut lsblk --discard wird TRIM bei diesen externen SSDs nicht unterstützt. Ich vermute, dass dies am Controller im Gehäuse liegt – selbst bei der neuen Samsung T9!

Interessante Beobachtung:

  • Eine interne Samsung 980 oder 990 Pro (NVMe) funktioniert problemlos mit TRIM.
  • Schließe ich diese extern an (in einem ORICO NVMe-Gehäuse mit USB4), wird TRIM ebenfalls unterstützt, wenn ich sie an meinen Thunderbolt 4 Rechner anschließe.
  • Verwende ich jedoch ein USB3.x zu SATA-Adapter in einem externen SSD-Gehäuse, wird der TRIM-Befehl blockiert oder nicht weitergeleitet (geprüft mit lsblk --discard und sudo fstrim -av).

Meine Lösung:

  • btrfs nutze ich nur für SSDs, die TRIM unterstützen (hauptsächlich wegen der schnellen Snapshots).
  • Für alle anderen SSDs greife ich auf ext4 zurück – wegen der hohen Stabilität und geringen Fragmentierung. ext4 überschreibt Daten direkt, unabhängig davon, ob TRIM verfügbar ist.
  • Bislang hatte ich mit dieser Methode keine Probleme. Selbst eine alte Samsung T3 mit NTFS, die als NAS an einer Fritzbox läuft, macht keine Schwierigkeiten.
  • In Zukunft werde ich nur noch NVMe SSDs in externen Gehäusen nutzen, welche TRIM-Passthrough unterstützen.

Fragen an euch:

  • Wie geht ihr mit externen SSDs und TRIM um?
  • Ist meine Einschätzung zum Thema TRIM-Passthrough und externen Gehäusen korrekt?
  • Habt ihr eine ähnliche Strategie oder andere Ansätze?

Ich freue mich auf eure Erfahrungen und Tipps!

1 Like

Ich sehe nach, wann TRIM bei den SSDs ausgeführt wurde (systemctl status fstrim.timer) und wenn dies zu lange zurück liegt, führe ich fstrim -Av aus.

Required:

  • UASP + TRIM supported external enclosure
  • lsusb → example:
    Bus 003 Device 002: ID 152d:0567 JMicron Technology Corp.
  • Edit /etc/udev/rules.d
    sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules
    Content:
    ACTION==“add|change”, ATTRS{idVendor}==“152d”, ATTRS{idProduct}==“0567”, SUBSYSTEM==“scsi_disk”, ATTR{provisioning_mode}=“unmap”

nano: save/close
F3
enter
F2
Manual trim test:
sudo fstrim -av


mod. comment: Last line has wrong quote characters, should be read as:

ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0567", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
3 Likes

Ich nutze Manjaro auf einer Samsung T5 angeschlossen über den normalen USB 3.0 anschluss, weil USB-C bei meiner SSD zugriffsfehler im journal erzeugt.

Ich habe bis jetzt gar nicht gewußt das Trim probleme macht oder ich bekomme das vielleicht nur nicht mit?

Ich hab vor knapp 4 Jahren Trim eingeschaltet mit:

sudo systemctl start fstrim.timer
systemctl enable --now fstrim.timer

Und gecheckt ob Trim läuft mit:

systemctl status fstrim.timer

● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: disabled)
     Active: active (waiting) since Mon 2024-12-30 18:05:07 CET; 13min ago
 Invocation: 292169494b904b428ab471af682baa08
    Trigger: Mon 2025-01-06 00:36:33 CET; 6 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Dez 30 18:05:07 koboldx-z170 systemd[1]: Started Discard unused filesystem blocks once a week.

Edit:

sudo fstrim -av
[sudo] password for koboldx: 
/media/nvme-games: 1,4 TiB (1573876477952 bytes) trimmed on /dev/nvme0n1p1

So wie es ausschaut läuft Trim auf meiner externen Samsung SSD wohl ebenfalls nicht.

Danke für dein Feedback! Ich glaube, da gibt es ein kleines Missverständnis. Meine Frage bezieht sich auf externe SSDs, die laut lsblk --discard kein TRIM unterstützen – vermutlich wegen des Controllers im externen Gehäuse. In diesen Fällen wird fstrim -av nicht ausgeführt, und der fstrim.timer ändert daran auch nichts.

TRIM funktioniert bei mir nur für die fest verbaute M.2 SSD im PC oder für externe SSDs mit Thunderbolt 4. Das Problem tritt vor allem bei USB-SATA-Adaptern und externen SSD-Gehäusen auf.

Wenn die externe Samsung SSD eingehängt ist, was zeigt lsblk --discard an?

PS: USB-C beschreibt nur die Form des Steckers – nicht die Geschwindigkeit oder das Protokoll der Verbindung. Ein Gerät mit USB-C kann intern verschiedene Standards nutzen (hoffe, ich erzähle jetzt keinen Quatsch): USB 2.0, 3.0, 3.1, 3.2, Thunderbolt 3 oder 4 (USB4). Diese ganzen USB-Standards sorgen doch nur für Verwirrung… :thinking:

Danke growler! Das funktioniert allerdings nur mit externen SSDs, die UASP (USB Attached SCSI Protocol) unterstützen und TRIM grundsätzlich erlauben. Ich musste diesen Weg für eine externe SSD wählen, die mit LUKS verschlüsselt ist.

Ich nehme das zurück – die Sache mit LUKS hatte mich damals wohl etwas verwirrt, da TRIM bei LUKS-verschlüsselten Geräten explizit erlaubt werden muss. Das geht zum Beispiel so:
sudo cryptsetup --allow-discards --persistent refresh luks-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Irgendwie war ich wohl auf dem Holzweg – aber wie auch immer: Ich habe es gerade mit meiner T7 an einem Raspberry Pi 4 getestet, die udev-Regel erstellt, und TRIM funktioniert!

lsblk --discard
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       4G         0
├─sda1        0      512B       4G         0
└─sda2        0      512B       4G         0
zram0         0        4K       2T         0
[pi4m@manjaro-arm ~]$ sudo fstrim -av
/boot: 406,5 MiB (426221568 Bytes) auf /dev/sda1 getrimmt
/: 909,8 GiB (976845414400 Bytes) auf /dev/sda2 getrimmt

:+1:

1 Like

Um bei SATA-disks die Kompatibilität der trim-Funktion zu prüfen, gibt es einen anderen (als root auszuführenden) Befehl:

# hdparm -I /dev/sdX | grep TRIM

Eine verschlüsselte Platte sollte übrigens niemals getrimmt werden, da damit eine Kompromittierung der Sicherheit der Verschlüsselung verbunden sein kann.

Ansonsten gibt es noch einen hilfreichen Archlinux wiki-Eintrag bzgl. Trimmen von externen SSDs (allerdings in Englisch).

1 Like

OK, wenn ich das richtig verstehe, wird daher standardmäßig TRIM bei LUKS deaktiviert, um diese Schwachstelle zu vermeiden. Ausser man erlaubt es explizit.

$ lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0      512B       2G         0
├─sda1             0      512B       2G         0
├─sda2             0      512B       2G         0
└─sda4             0      512B       2G         0
sdb                0        0B       0B         0
├─sdb1             0        0B       0B         0
├─sdb2             0        0B       0B         0
└─sdb3             0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
├─sdc2             0        0B       0B         0
├─sdc3             0        0B       0B         0
└─sdc4             0        0B       0B         0
nvme0n1            0      512B       2T         0
└─nvme0n1p1        0      512B       2T         0

Meine externe usb platte ist sdc.

Bus 002 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd Portable SSD T5

Wie muß ich das denn dort übernehmen?

Richtig so? Nur die zwei zahlen werte ersetzen?

Ja, wenn du deine VendorID als ‘04e8’ und ProductID als ‘61f5’ ermittelt hast, trägst du das mit dem Befehl sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules ein:

ACTION==“add|change”, ATTRS{idVendor}==“04e8”, ATTRS{idProduct}==“61f5”, SUBSYSTEM==“scsi_disk”, ATTR{provisioning_mode}=“unmap”

Dann die udev-Regeln neu laden und anwenden:

sudo udevadm control --reload-rules
sudo udevadm trigger

Testen:

lsblk --discard
sudo fstrim -av /run/media/koboldx/NAME-deiner-T5/

Viel Erfolg!

1 Like

Leider funktioniert es nicht bei mir :frowning:
Hab sogar neu gestartet aber trim funktioniert nur bei meiner nvme.

[koboldx@koboldx-z170 ~]$ sudo udevadm control --reload-rules
[sudo] password for koboldx: 
[koboldx@koboldx-z170 ~]$ sudo udevadm trigger
[koboldx@koboldx-z170 ~]$ lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0      512B       2G         0
├─sda1             0      512B       2G         0
├─sda2             0      512B       2G         0
└─sda4             0      512B       2G         0
sdb                0        0B       0B         0
├─sdb1             0        0B       0B         0
├─sdb2             0        0B       0B         0
└─sdb3             0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
├─sdc2             0        0B       0B         0
├─sdc3             0        0B       0B         0
└─sdc4             0        0B       0B         0
nvme0n1            0      512B       2T         0
└─nvme0n1p1        0      512B       2T         0
[koboldx@koboldx-z170 ~]$ sudo fstrim -av
/media/nvme-games: 1,4 TiB (1573748441088 bytes) trimmed on /dev/nvme0n1p1

Ich habe die udev rules mit den inhalt wie oben erstellt.

ACTION==“add|change”, ATTRS{idVendor}==“04e8”, ATTRS{idProduct}==“61f5”, SUBSYSTEM==“scsi_disk”, ATTR{provisioning_mode}=“unmap”

Die logs zeigen weiterhin keine veränderung für sdc, die Samsung T5 auf der ich Manjaro am laufen habe.
:man_shrugging:

I have no idea what i did wrong, maybe it is because i miss the point for what reason is F3 enter F2 is about and where to use this?

Ich denke, mit F3 ist das Speichern gemeint und mit F2 das Beenden des Nano-Editors. Falls es beim T5 nicht funktioniert, könnte es am SATA-Controller liegen. Wie gesagt, bei meiner T7 hat es funktioniert. Nächste Woche komme ich möglicherweise an eine T5 bei einem Freund und werde es dann testen und berichten.

Vielleicht möchtest du sicherheitshalber die Konsolenausgabe deiner Vorgehensweise genau mit uns teilen?

Ausgabe von:
lsusb

den Inhalt zeigen:
sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules

dann:
sudo udevadm control --reload-rules && sudo udevadm trigger

und die Ausgabe dieser 2 Zeilen (den Namen anpassen):

lsblk --discard
sudo fstrim -v /run/media/koboldx/NAME-deiner-T5/
1 Like

Eigentlich habe ich oben bereits alles an output geposted.

Aber wenn du willst kann ich das nochmal machen.

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1bcf:08b8 Sunplus Innovation Technology Inc. HID Gaming Mouse
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd Portable SSD T5
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
ACTION==“add|change”, ATTRS{idVendor}==“04e8”, ATTRS{idProduct}==“61f5”, SUBSYSTEM==“scsi_disk”, ATTR{provisioning_mode}=“unmap”
$ lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0      512B       2G         0
├─sda1             0      512B       2G         0
├─sda2             0      512B       2G         0
└─sda4             0      512B       2G         0
sdb                0        0B       0B         0
├─sdb1             0        0B       0B         0
├─sdb2             0        0B       0B         0
└─sdb3             0        0B       0B         0
sdc                0        0B       0B         0
├─sdc1             0        0B       0B         0
├─sdc2             0        0B       0B         0
├─sdc3             0        0B       0B         0
└─sdc4             0        0B       0B         0
nvme0n1            0      512B       2T         0
└─nvme0n1p1        0      512B       2T         0

Keine ahnung was ich da eingeben soll.


sudo fstrim -av
/media/nvme-games: 1,4 TiB (1573748441088 bytes) trimmed on /dev/nvme0n1p1

Findet halt nur die nvme.

sudo fstrim -av /dev/sdc
fstrim: unexpected number of arguments

Funktioniert hier auch nicht.

Sys Info’s:

Drives:
  Local Storage: total: 5.93 TiB used: 432.29 GiB (7.1%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Corsair model: MP600 PRO LPX
    size: 1.82 TiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: EIFM31.6 temp: 31.9 C
    scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 PRO 1TB
    size: 953.87 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
    tech: SSD serial: <filter> fw-rev: 2B6Q scheme: MBR
  ID-3: /dev/sdb maj-min: 8:16 vendor: HGST (Hitachi) model: HDN724030ALE640
    size: 2.73 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
    tech: HDD rpm: 7200 serial: <filter> fw-rev: A5E0 scheme: GPT
  ID-4: /dev/sdc maj-min: 8:32 vendor: Samsung model: Portable SSD T5
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B type: USB
    rev: 3.1 spd: 5 Gb/s lanes: 1 mode: 3.2 gen-1x1 tech: SSD serial: <filter>
    scheme: MBR
  Message: No optical or floppy data found.
Partition:
  ID-1: / raw-size: 88.61 GiB size: 86.66 GiB (97.80%) used: 24.29 GiB (28.0%)
    fs: ext4 dev: /dev/sdc1 maj-min: 8:33 label: N/A
    uuid: eb235aa7-d461-413d-800e-ea57385703fb
  ID-2: /boot raw-size: 2.93 GiB size: 2.82 GiB (96.15%)
    used: 126.6 MiB (4.4%) fs: ext3 dev: /dev/sdc3 maj-min: 8:35 label: N/A
    uuid: cbfeca98-b99d-4383-9ded-fe66cd598006
  ID-3: /home raw-size: 332.03 GiB size: 325.75 GiB (98.11%)
    used: 16.49 GiB (5.1%) fs: ext4 dev: /dev/sdc4 maj-min: 8:36 label: N/A
    uuid: ada4a6a2-bd0a-4652-b386-7c637bba7ee9
Swap:
  Kernel: swappiness: 10 (default 60) cache-pressure: 100 (default) zswap: yes
    compressor: zstd max-pool: 20%
  ID-1: swap-1 type: partition size: 7.81 GiB used: 103.2 MiB (1.3%)
    priority: -2 dev: /dev/sdc2 maj-min: 8:34 label: N/A
    uuid: 717b267e-7322-4bf9-a840-f1210d422d1a

Das wäre super, danke :slight_smile:

Prost Neujahr!

Ich konnte soeben TRIM erfolgreich auf meiner alten Samsung T3 SSD durchführen, die ich für BackInTime nutze. Der reservierte Speicherplatz ist auf 0 % gesetzt – das hat jedoch keinen Einfluss auf TRIM. Hier ist die genaue Vorgehensweise:

1. Ausgangslage

  • SSD: Samsung T3
  • Dateisystem: ext4 (eine Partition)
  • Mountpoint: /run/media/jo/BackupT3

2. Problem – TRIM wird nicht unterstützt

Erster Versuch:

sudo fstrim -v /run/media/jo/BackupT3/

Fehlermeldung:
fstrim: /run/media/jo/BackupT3/: Verwerfungsvorgang wird nicht unterstützt.

3. Gerät identifizieren (lsblk)

Zuerst wird das Blockgerät identifiziert:

lsblk

In meinem Fall:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465,8G  0 disk 
└─sda1        8:1    0 465,8G  0 part /run/media/jo/BackupT3

4. TRIM-Unterstützung prüfen

lsblk --discard /dev/sda

Ergebnis:

NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      0B       0B         0
└─sda1        0      0B       0B         0

TRIM wird nicht unterstützt.

5. TRIM für externe SSDs aktivieren (udev-Regel erstellen)

Schritt 1 – Geräteinformationen abfragen:

lsusb

Ausgabe der Samsung T3:

Bus 001 Device 013: ID 04e8:61f3 Samsung Electronics Co., Ltd Portable SSD T3

Schritt 2 – udev-Regel erstellen:

sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules

Regel einfügen (mit passender Vendor- und ProductID), je SSD in einer Zeile:

# Samsung T3 SSD (TRIM aktivieren)
ACTION=="add|change", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="61f3", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Speichern und schließen mit F2.

6. udev-Regeln neu laden und anwenden

sudo udevadm control --reload-rules && sudo udevadm trigger

7. TRIM erneut testen

lsblk --discard

Ergebnis nach Regel:

NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0      512B       4G         0
└─sda1             0      512B       4G         0

TRIM ausführen:

sudo fstrim -v /run/media/jo/BackupT3/
/run/media/jo/BackupT3/: 457,3 GiB (491070849024 Bytes) getrimmt

PS: Wie hier schon erwähnt wurde, kannst du eine TRIM-Unterstützung auch per hdparm prüfen.

sudo hdparm -I /dev/sda | grep -i trim

Ergebnis bei mir:
* Data Set Management TRIM supported (limit 8 blocks)

1 Like

Frohes neues!
Hab es jetzt mit den richtigen Mountpoints ebenfalls versucht, wird aber wohl nicht unterstützt.

[koboldx@koboldx-z170 ~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 953,9G  0 disk 
├─sda1        8:1    0    50M  0 part 
├─sda2        8:2    0  97,1G  0 part 
└─sda4        8:4    0 782,5G  0 part 
sdb           8:16   0   2,7T  0 disk 
├─sdb1        8:17   0  63,5G  0 part /media/temp
├─sdb2        8:18   0   1,6T  0 part 
└─sdb3        8:19   0   1,1T  0 part 
sdc           8:32   0 465,8G  0 disk 
├─sdc1        8:33   0  88,6G  0 part /
├─sdc2        8:34   0   7,8G  0 part [SWAP]
├─sdc3        8:35   0   2,9G  0 part /boot
└─sdc4        8:36   0   332G  0 part /home
nvme0n1     259:0    0   1,8T  0 disk 
└─nvme0n1p1 259:1    0   1,8T  0 part /media/nvme-games
[koboldx@koboldx-z170 ~]$ sudo fstrim -v /
[sudo] password for koboldx: 
fstrim: /: the discard operation is not supported
[koboldx@koboldx-z170 ~]$ sudo fstrim -v [SWAP]
fstrim: stat of [SWAP] failed: No such file or directory
[koboldx@koboldx-z170 ~]$ sudo fstrim -v /boot
fstrim: /boot: the discard operation is not supported
[koboldx@koboldx-z170 ~]$ sudo fstrim -v /home
fstrim: /home: the discard operation is not supported
$ sudo hdparm -I /dev/sdc | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Sieht so aus als wäre es doch supported? Aber wieso dann das manuelle trim nicht will versteh ich nicht.

:man_shrugging:

Sorry, da kann ich leider nicht weiterhelfen. Da TRIM auf meiner T3 und T7 problemlos funktioniert, sollte es eigentlich auch mit der T5 klappen – vor allem, wenn hdparm meldet, dass TRIM unterstützt wird. Was zeigt lsusb -t bei dir an?

Bei mir wird UASP aktiv verwendet (Driver=uas):

|__ Port 003: Dev 013, If 0, Class=Mass Storage, Driver=uas, 480M

Falls bei dir stattdessen usb-storage erscheint, wird UASP nicht verwendet – und das blockiert TRIM.

$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
    |__ Port 013: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 013: Dev 002, If 1, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 5000M
    |__ Port 005: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M

Bus 002/Port 005 Sieht okay aus, würde ich sagen.

Ich versteh es auch nicht, vielleicht ist an meiner T5 irgend etwas speziell?

Oder weil ich darauf aktive Manjaro am laufen habe und du nicht?

Kam bei dir auch die meldung bei der erstellung der udev regel in Nano mit Modified buffer und ob du das abspeichern möchtest mit ja?

Oder hast du vielleicht eine neuere oder ältere Firmware installiert als ich?
Die vielleicht eine bessere Kompatibilität hat für Linux.

KDE Partition Manager zeigt mir bei den Smartwerte die Firmware an:
MVT42P1Q

So weit ich mich dran erinnern kann, habe ich die firmware ende 2020 noch geupdated.

Ich bin mir nicht sicher, was du mit “aktive Manjaro” meinst. Auf meinen Desktops läuft überall Manjaro x86 KDE Plasma (stable). Nur auf meinem Pi4 nutze ich Manjaro ARM (headless, testing oder unstable). In beiden Fällen funktioniert TRIM mit der udev-Regel problemlos.

Kam bei dir die Meldung “Modified buffer” in Nano, als du die udev-Regel erstellt hast, und wurdest du gefragt, ob du speichern möchtest?

→ Nein

Prüf bitte deine udev-Regel, um sicherzustellen, dass TRIM aktiviert wurde:
cat /etc/udev/rules.d/50-usb-ssd-trim.rules

PS: Ich vermute, du hast dich nicht ganz exakt an meine Vorgehensweise gehalten. Geh die Schritte am besten nochmal durch und nutze Copy & Paste, um Fehler zu vermeiden. Falls es weiterhin nicht klappt, poste die Konsolenausgabe hier – dann schauen wir gemeinsam drüber.

Kurzer Einschub, der nur bedingt zur Frage gehört:
Die Fritz-Boxen liefern eine vergleichsweise schlechte Performance als NAS-Speicher.
Ich würde mittelfristig über eine andere Lösung mittels NAS-Box nachdenken. Selbst mit einem Raspberry 4 oder 5 läuft das besser.

Ich hatte meine Platten vor einigen Jahren auch an der Box, bin dann aber schnell wieder davon weg. Sie war einfach der Flaschenhals

  • List item