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.