Liebe Kolleg:innen

Für eine NTFS-Partition (formatiert unter Windows 10) erscheint folgende Fehlermeldung, wenn ich den fstrim-Befehl auslöse:

fstrim: /media/daten: the discard operation is not supported

Die Partition wird folgendermassen gemountet:

mount -t ntfs3 -o rw,noatime UUID=B4CC5D0CCC5CC9EE /media/daten

Im englischsprachigen Arch-Wiki steht, fstrim unter NTFS-3G werde seit Version 2015.3.14 unterstützt, nicht jedoch die Option "discard".

lsblk --discard zeigt:

NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1            0      512B       2T         0
├─nvme0n1p1        0      512B       2T         0
├─nvme0n1p2        0      512B       2T         0
├─nvme0n1p3        0      512B       2T         0
├─nvme0n1p4        0      512B       2T         0
├─nvme0n1p5        0      512B       2T         0
├─nvme0n1p6        0      512B       2T         0
└─nvme0n1p7        0      512B       2T         0

Die fragliche Partition ist nvme0n1p4; für diese sind sowohl DISC-GRAN als auch DISC-MAX ungleich null, der trim-Support sollte also vorhanden sein.

Für nvme0n1p1 (/boot) und nvme0n1p5 (/, ext4) funktioniert fstrim ohne Fehlermeldung.

Die mount-Option -o rw,noatime,discardbringt keine Abhilfe.

Hat jemand eine Idee, wie ich für die NTFS-Partition den fstrim-Befehl ausführen kann, ohne ins Windows wechseln zu müssen?

Vielen Dank für eure Tips!

Rolf

  • Caramon2 hat auf diesen Beitrag geantwortet.

    ntfs-3g ist aber was ganz anderes (ntfs per FUSE), das ntfs3 ist der Dateisystemtreiber im Kernel.

    Also stattdessen mit ntfs-3g mounten und probieren.

    • rf hat auf diesen Beitrag geantwortet.

      Hallo frostschutz

      ntfs-3g ist aber was ganz anderes (ntfs per FUSE), das ntfs3 ist der Dateisystemtreiber im Kernel.

      Ui, da hast du natürlich recht. Mein Fehler, bitte entschuldige.

      Also stattdessen mit ntfs-3g mounten und probieren.

      Da kann ich wohl auf meinen Post vom 18. Mai verweisen. Damals erhielt ich die Fehlermeldung:

      [W] ntfs-3g seems unsupported by the current kernel

      Mittlerweile bin ich aber noch auf diesen Post von Februar 2021 gestossen, in dem auch ntfs3 erwähnt wird. Dort schreibst du u. a.:

      fstrim macht man ja nur gelegentlich, also der Workaround - alten Kernel/Livesystem booten und von dort an fstrim ausführen und zurück - wäre hier machbar.
      Die Welt geht auch nicht unter wenn man fstrim komplett weglässt. TRIM ist sehr überbewertet.

      Vielleicht ist es besser, wenn ich es einfach damit bewenden lasse?

      Herzliche Grüsse

      Rolf

        Ja, naja die Welt geht nicht unter, erst recht nicht wenn das nur eine kleine Partition auf einer großen SSD ist und der Rest eh getrimmt wird.

        Aber eigentlich sollte das mit ntfs-3g noch / wieder tun, dieser Regression Bug da in dem alten Thread wurde ja letztendlich doch irgendwie umschifft.

        Die von dir gepostete Meldung stammt ja von findmnt, hast du denn auch eine Fehlermeldung von ntfs-3g selbst?

        Ansonsten eben abwarten ob ntfs3 irgendwann auch noch FITRIM lernt und damit fstrim unterstützt.

        • rf hat auf diesen Beitrag geantwortet.
          rf hat den Titel zu [gelöst] fstrim mit ntfs3: "the discard operation is not supported" geändert ().

          Hallo frostschutz

          Danke vielmals für deinen HInweis betr. ntfs-3g! Ich habe die Parition jetzt damit gemountet anstatt mit ntfs3, und fstrim gibt keine Fehlermeldung mehr aus.

          Den systemd-Dienst, den ich in meinem oben erwähnten Post vom 18. Mai erwähnte, werde ich entsprechend anpassen.

          Immer wieder erstaunlich, auf welche eigentlich naheliegenden Dinge ich erst dank des Forums komme ... Das Arch-Wiki und das Arch-Forum sind für mich eine wahre Goldgrube, vielen Dank an alle daran Beteiligten!

          Herzliche Grüsse

          Rolf

            Dirk hat den Titel zu fstrim mit ntfs3: "the discard operation is not supported" geändert ().
            Dirk hat das Thema gelöst hinzugefügt ().

            Hallo Dirk

            Danke für den Hinweis! Ich werd's mir merken für ein nächstes Mal.

            Herzliche Grüsse

            Rolf

              5 Monate später

              rf Die mount-Option -o rw,noatime,discardbringt keine Abhilfe.

              Die Mount-Option "discard" (egal ob ntfs-3g oder ntfs3) hat nichts mit fstrim zu tun, sondern aktiviert online-discard: D. h. beim löschen einer Datei wird der davon belegt Bereich sofort getrimmt.

              Das hat den Nachteil, dass es langsamer ist, aber da halbwegs aktuelle SSDs das cachen, ist das bei großen Dateien zwar spürbar, aber nicht wirklich relevant. Gravierender ist eher, dass z. B. eine versehentlich gelöschte Datei nicht wiederhergestellt werden kann, da sie ja praktisch "sicher" gelöscht wurde.

              Da ich aus Geschwindigkeitsgründen (DVB-Bearbeitung per AVIdemux) nicht auf ntfs3 verzichten will, hatte ich mit ein Skript "ntfsclean" geschrieben (als ausfühbar markieren und im Pfadt speichern):

              #!/bin/bash
if [ $# == 0 ];then echo "ntfsclean /dev/sd?? …";exit;fi
while [ $# -gt 0 ]
do umount -l /dev/sd$1* 2>/dev/null
sudo ntfswipe -dm /dev/sd$1
sudo ntfs-3g /dev/sd$1 /mnt/
echo;sudo fstrim -v /mnt/;echo
sudo umount -l /mnt/
shift;done

              Mit z. B. "ntfsclean c1 d1" trimmt man /dev/sdc1 und /dev/sdd1 nacheinander.

              Wichtig ist dabei, dass die betreffenden Partitionen ausgehängt sind, oder nur als normaler Nutzer eingehängt, aber nicht belegt, da "unmount" (aus sicherhitsgründen ohne "sudo") sie sonst nicht aushängen kann.

              Das vorherhige "ntfswipe" bereinigt nur die gelöschten Datenen/Verzeichnisse, da die nach fstrim ja sowieso nicht wiederherstellbar sind und so die Liste von z. B. "ntfsundelete" nicht unnötig zugemüllt ist, wenn man es mal braucht.

              Nachrag:

              Um NTFS-Laufwerke/-Partitionen automatisch mit ntfs3 zu nutzen, erstellt man die Datei "/etc/udev/rules.d/99-ntfs3.rules":

              # ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)

SUBSYSTEM=="block",ENV{ID_FS_TYPE}=="ntfs",ENV{ID_FS_TYPE}="ntfs3",ENV{UDISKS_FILESYSTEM_SHARED}="0"

              Btw:

              Ich hatte auch mal als Alternative die "wiper.sh" genutzt, da die auch mit ntfs3 klar zu kommen schien, aber ich habe dann festgestellt, dass sie nur bei internen SSDs funktioniert.

              Bei externen SATA-SSDs (in trimmbaren USB3-Gehäusen) wird zwar "succeeded" ausgegeben, aber wenn ich die betreffende Partition mit "dd" auslese, enthält sie weiterhin die gelöschten Daten (die SSD liefert "ZEROs after TRIM" - hätte Trim funktioniert, dürften nur Nullen kommen):

              # sync;wiper.sh --commit --please-prematurely-wear-out-my-ssd /run/media/user/Test/;sync

              wiper.sh: Linux SATA SSD TRIM utility, version 3.6, by Mark Lord.
              Preparing for online TRIM of free space on /dev/sdc2 (xfs mounted read-write at /run/media/user/Test).
              Allocating temporary file (32059266 KB)..
              Syncing disks..
              Beginning TRIM operations..

              /dev/sdc:
              trimming 33495162 sectors from 512 ranges
              SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
              succeeded
              trimming 30623374 sectors from 468 ranges
              SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
              succeeded
              Removing temporary file..
              Syncing disks..
              Done.

              Da ich dem auch bzgl. internen SSDs nicht mehr traue (erscheint mir eher wie Glücksache), rate ich von der "wiper.sh" ab.