• Café

  • fstrim funktioniert nicht mehr mit ntfs

Hallo!

Da ich mich gerade erst angemeldet habe, Artix nutze und dieses mein erster regulärere Beitrag ist (hier hatte ich als Gast geschrieben: https://forum.archlinux.de/viewtopic.php?pid=379102#p379102 ), schreibe ich das hier lieber im Café:

Ich nutze zwar Artix, aber auch bei Arch ist das ab Kernel 5.10 so:

https://bbs.archlinux.org/viewtopic.php?id=262243

Ich habe es mit Kernel 5.10.{4,6,8,10,12), zen-5.10.{12,15}, dem aktuellen Solus 4.2 (Kernel 5.10.12) und auf unter LinuxMint 18.3 mit dem Mainline-Kernel 5.10.6 reproduziert ( https://kernel.ubuntu.com/kernel-ppa/mainline/ - alle anderen 5.10er nicht getestet, mit dem 5.9.16 funktioniert es noch, wie auch bei Artix mit dem letzten 5.9er: 5.9.14): Immer kommt die Meldung, dass das Gerät belegt ist.

Die NTFS-Partition lässt sich nur noch ausgehängt per wiper.sh von hdparm trimmen.

Nachtrag vom 06.12.22: Von der wiper.sh rate ich inzwischen ab.

Aufgrund des obigen Threads vermute ich, dass ntfs-3g den alten ntfs-Kernel-Treiber nutzt, um zu prüfen, ob die Partition belegt ist, und da er den nicht mehr gibt, kommt es zu diesem Fehler: Also ntfs-3g muss imo angepasst werden.

Mit dem aktuellen ntfs-3g-ar funktioniert es aber noch nicht: https://aur.archlinux.org/packages/ntfs-3g-ar/

Im Zuge der Tests bin ich auch auf ntfs3 gestoßen, was ab 5.12 in den Kernel kommen soll, aber das unterstützt fstrim noch überhaupt nicht: https://aur.archlinux.org/packages/ntfs3-dkms/ - wiper.sh kann es entgegen ntfs-3g aber auch eingehängt trimmen.

Könnte das jemand ggfs. an die betreffenden Stellen weiterleiten? Ich kenne mich da nicht aus.

Btw: Mich wundert daran, dass es bis vor kurzen nur diesen einen Thread gab und auch kaum etwas und nichts konkretes: Nutzt fast niemand ntfs auf SSDs, oder fällt das nur keinem auf?

Freundliche Grüße,

Andreas

Laut dem von dir verlinkten Bugreport ist das ein gewünschtes verhalten und kein Bug. Wenn das Gerät belegt ist, sollte das auch gemeldet werden. Die Frage ist, wodurch es belegt ist. Das bekommt man mit lsof heraus.
Hmmm...
"8\0\0\0\3\0\0\0^\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 135168) = 56
14:57:09.387124 writev(4, [{iov_base="x\0\0\0\0\0\0\0^\0\0\0\0\0\0\0", iov_len=16}, {iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0"..., iov_len=104}], 2) = 120
14:57:09.387258 read(4, "0\0\0\0\"\0\0\0`\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 135168) = 48
14:57:09.387377 writev(4, [{iov_base="\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0", iov_len=16}], 1) = 16
14:57:09.387449 read(4, "0\0\0\0\33\0\0\0b\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 135168) = 48
14:57:09.387494 writev(4, [{iov_base=" \0\0\0\0\0\0\0b\0\0\0\0\0\0\0", iov_len=16}, {iov_base="\220?\377\261\tV\0\0\0\0\0\0\0\0\0\0", iov_len=16}], 2) = 32
14:57:09.387530 read(4, "`\0\0\0'\0\0\0d\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 135168) = 96
14:57:09.387565 stat("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x7, 0), ...}) = 0
14:57:09.387602 openat(AT_FDCWD, "/sys/dev/block/7:0/discard_alignment", O_RDONLY) = 6
14:57:09.387641 newfstatat(6, "", {st_mode=S_IFREG|0444, st_size=4096, ...}, AT_EMPTY_PATH) = 0
14:57:09.387669 read(6, "0\n", 4096)    = 2
14:57:09.387697 close(6)                = 0
14:57:09.387723 openat(AT_FDCWD, "/sys/dev/block/7:0/queue/discard_granularity", O_RDONLY) = 6
14:57:09.387750 newfstatat(6, "", {st_mode=S_IFREG|0444, st_size=4096, ...}, AT_EMPTY_PATH) = 0
14:57:09.387775 read(6, "4096\n", 4096) = 5
14:57:09.387799 close(6)                = 0
14:57:09.387821 openat(AT_FDCWD, "/sys/dev/block/7:0/queue/discard_max_bytes", O_RDONLY) = 6
14:57:09.387846 newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=4096, ...}, AT_EMPTY_PATH) = 0
14:57:09.387870 read(6, "4294966784\n", 4096) = 11
14:57:09.387896 close(6)                = 0
14:57:09.387922 fsync(3)                = 0
14:57:09.387976 pread64(3, "\367\377\177\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 134246400) = 4096
14:57:09.388020 ioctl(3, BLKDISCARD, [12288, 4096]) = -1 EBUSY (Device or resource busy)
14:57:09.388058 writev(4, [{iov_base="8\0\0\0\0\0\0\0d\0\0\0\0\0\0\0", iov_len=16}, {iov_base="\360\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}, {iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=24}], 3) = 56
14:57:09.388099 read(4, "@\0\0\0\35\0\0\0f\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 135168) = 64
14:57:09.388200 writev(4, [{iov_base="\20\0\0\0\0\0\0\0f\0\0\0\0\0\0\0", iov_len=16}], 1) = 16
14:57:09.388252 read(4,
Die Frage ist, wodurch es belegt ist.
Durch ntfs3g selbst ... ;-)
Die Frage ist dann wo das EBUSY auf einmal herkommt...

Vielleicht ist es das hier:

https://lore.kernel.org/linux-block/20200825120554.13070-3-jack@suse.cz/

https://lore.kernel.org/linux-block/20200904085852.5639-3-jack@suse.cz/

https://github.com/torvalds/linux/commit/384d87ef2c954fc58e6c5fd8253e4a1984f5fe02

Edit: ach lesen müsste man können, das steht ja schon längst im Bugreport, und ich such mir nen Wolf LOL
stefanhusmann schriebLaut dem von dir verlinkten Bugreport ist das ein gewünschtes verhalten und kein Bug. Wenn das Gerät belegt ist, sollte das auch gemeldet werden. Die Frage ist, wodurch es belegt ist. Das bekommt man mit lsof heraus.
Ich hatte nicht gesehen, dass im Bugreport inzwischen ein weiterer Bugrport verlinkt ist, nachdem sich einen Monat lang fast gar nichts tat und ich auch per Google nichts anderes dazu finden konnte.

So wie ich dessen Aussage verstehe, kann fstrim, was extra dafür da ist, eingehängte Partitionen zu trimmen, ntfs jetzt nicht mehr trimmen *weil* es eingehängt ist!?

Durch lsof blicke ich nicht durch: Wenn ich die Ausgabe per grep eingrenze, greift nur mount.ntfs auf die Partition zu. - Das lässt sich ja nicht vermeiden.

Entweder hat da jemand eine ziemlich behämmerte Idee gehabt, das so umzusetzen, oder es ist doch ein Bug.

Ich hatte bisher jedenfalls nie Probleme, obwohl ich die ntfs-Partition für Videoschnitt brauche (DVB-S, mit VideReDo per VM-XP unter KVM) und gelegentlich sogar mehrmals täglich trimme, weil wieder ein paar GiB kurzfristig drauf waren und ich nach dem löschen möglichst zeitnah trimme. - Dafür habe ich mir in Thunar extra eine benutzerdefinierte Aktion erstellt: RMB/Trim - Für ntfs brauchte fstrim bisher keine Root-Rechte.
So wie ich dessen Aussage verstehe, kann fstrim, was extra dafür da ist, eingehängte Partitionen zu trimmen, ntfs jetzt nicht mehr trimmen *weil* es eingehängt ist!?
ntfs ist halt kein Kernel-Dateisystem sondern ein Userspace-Dateisystem

fstrim schickt also an den Kernel das FITRIM ioctl, FUSE schickt es zurück an Userspace (ntfs3g Prozess), und der versucht wiederum an den Kernel ein BLKDISCARD ioctl zu schicken... und irgendwo in dieser Verkettung entsteht dann ein "sorry geht nicht".

Ob das jetzt allgemein ein Problem mit FUSE ist und somit alle FUSE-Dateisysteme nischt mehr (auf Blockgeräten mit BLKDISCARD) trimmen können, oder ob ntfs3g selber da irgendwas falsch macht, kann ich leider nicht beurteilen.

Hier bleibt wohl nur abwarten, mehr als daß ntfs3g- und Kernel-Entwickler an der Sache dran sind, kann man nicht erwarten.

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.
frostschutz schriebHier bleibt wohl nur abwarten, mehr als daß ntfs3g- und Kernel-Entwickler an der Sache dran sind, kann man nicht erwarten.

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.
1. Ja, endlich tut sich was. Ich hatte es nur leider zu spät gesehen, sonst hätte ich noch abgewartet, statt den Thread zu öffnen.

2. Wie geschrieben, brauche ich die ntfs-Partition für Videoschnitt: Da gehen hier zig GiB/Monat durch, auf einer 120 GB SSD: Das würde ohne Trim schnell relevant.

Momentan nutze ich noch LinuxMint 18.3 als Produktivsystem (mit Kernel 5.9.16 - kann also noch trimmen), aber dessen Tage sind gezählt.
Eigentlich müsste (aktuelles) Windows im KVM das auch selbst trimmen können oder du bootest eben ein Livesystem im KVM dafür. Das Durchreichen von discard vom Guest zum Host sollte ja hoffentlich noch funktionieren.

Oder du machst die ganze NTFS Partition mit blkdiscard platt und dann eine neue. Mit LVM könntest du für jedes Projekt ein NTFS Logical Volume der passenden Größe dafür anbieten. Bei so einer kleinen SSD nehme ich an daß du sowieso alles auf Festplatte schiebst wenn fertig?

Oder du nimmst auf dem Host ein Linuxdateisystem und die VM mit qcow Images und das TRIM erledigt dann das Hostdateisystem, da ist dann FUSE ganz aus dem Rennen... (aber auch hier müsste Windows selber NTFS trimmen können, wenn du altes Windows hast geht das wohl nicht)
Für mich habe ich eine Lösung gefunden (ntfs3+wiper.sh - s. o.), es geht mir hier generell um den "Bug".

ntfs3 hat zusätzlich den Vorteil, dass es *weit* schneller als ntfs-3g ist und online-discard unterstützt:

1. wenn ich mit AVIdemux ein mpg öffne, erstellt es währenddessen eine kleine .idx (es scannt das komplette mpg) und durch diese minimalen Schreibzugriffe schaltet ntfs-3g auf ungeheuer langsam. - Ich vermute aus lizenzrechtlichen Gründe, da ich das mit exfat, als es noch über fuse lief, nicht reproduzieren konnte.

Praktisch sieht das so aus, dass AVIdemux zum öffnen des selben 1,6 GiB mpg (Serien-Folge mit ca. 40 Min.) über ntfs3 5 Sek. braucht, über ntfs-3g dagegen 34 Sek. - Bei Spielfilmen entsprechend länger.

2. Wenn ich mir angewöhne nur noch von Linux aus lösche, brauche ich ntfs nicht mehr trimmen. - Die wiper.sh nutze ich dann nur gelegentlich, um auch das abzudecken, wovon der online-discard ggfs. nichts mitbekommen hat.

…

Das VM-XP (Home) hatte ich mir damals gekauft. Andere Windowsen besitze ich nicht.

Das will ich auch gar nicht tauschen, da schön schlank (das komprimierte .qcow2 hat gerade mal 269 MiB) und bei einem Vergleich das mit Abstand schnellste (die selbe Aufnahme vom selben Stick auf die selbe ntfs-Partition geschnitten):

VM-XP (2 Cores, 1 GiB RAM): 45 Sek.

Natives XP x64 (Octacore, 16 GiB RAM): 1 Min.

Natives Win10 x64 (dto. - alles auf dem selben PC): 2 Min.

Das VM-XP (per KVM/LinuxMint 18.3) ist dabei also mehr als doppelt so schnell wie ein "modernes" Windows!

Mehrfach mit unterschiedlichen Aufnahmen getestet: 100% reproduzierbar!
Ja, danke.

Ich verstehe das so, dass die das sicherer machen wollten und dabei übers Ziel hinaus geschossen sind. Jetzt wollen es nochmal überdenken und sich besser miteinander absprechen.

Das positive daran war für mich, dass ich so auf ntfs3 gestoßen bin, was viel schneller als ntfs-3g ist und sogar online-discard unterstützt.

Den Kommentar zum AUR nach ist es zwar noch etwas wackelig, aber mich hat das bisher nicht betroffen und die ntfs-Partition ist hier sowieso nur ein Zwischenschritt, weshalb trim dort wichtig ist:

Lt. SMART werden durchschnittlich 5,3 GiB/Tag geschrieben (also auch etwas später wieder gelöscht): Alle 3½ Wochen die volle Kapazität.
9 Tage später
13 Tage später
Auch mit dem 5.11.4-zen und dem 5.10.20-lts funktioniert fstrim auf ntfs noch nicht wieder.

wiper.sh funktioniert dagegen mit beiden und auch online-discard mit ntfs3. - fstrim wird von ntfs3 dagegen gar nicht unterstützt.

Btw:

Meine Test-SSD liefert zum Glück nach trim gleich Nullen, so dass ich das schnell testen kann.

Ich hatte das vor Jahren mal beschrieben (PDF):

https://drive.google.com/file/d/1-3XDpeQF80BO95Oo6MiB8b4uQw_ypIZa/view?usp=drivesdk

Den Rest davon nicht beachten: Damals wusste ich es nicht besser. - Irgendwann werde ich das überarbeiten…
Ja, da war ich leider zu optimistisch.

Der Revert wurde geändert in einen abgewandelten Patch und der lag erstmal ignoriert auf der Mailingliste herum

Laut https://lore.kernel.org/linux-block/53689a67-7591-0ad8-3e7d-dca9a626cd99@kernel.dk/T/ dann erst ab 5.12-rc3 im Kernel und von da muss es dann auch erst weiterwandern in 5.10.x.

Das scheint nicht auf dem beschleunigten Pfad für Regressions zu liegen und so dümpelt das jetzt vor sich hin... aber mehr als auf dem Bugtracker darauf hinweisen, daß das noch ganz andere Sachen betrifft, kann ich da auch nicht machen.
Danke, dass du dich darum kümmerst.

Falls das falsch rüber gekommen ist: Ich wollte mich nicht beschweren, sondern meinte das als Status-Update.

Wie gesagt: Ich habe davon ja sogar profitiert, da ich so auf ntfs3 gestoßen bin, was für meinen Anwendungszweck sehr viel leistungsfähiger ist.

Btw:

Da ich neu bin und das zuerst nicht einschätzen konnte, hatte ich es im Cafe geschrieben. Aber so wie es sich entwickelt hat, wäre der Thread in "Linux allgemein" nicht besser aufgehoben?
5 Tage später
ist laut changelog in 5.10.24, 5.11.7 und 5.12-rc3
Danke.

Nachtrag:

fstrim vs. ntfs-3g funktioniert mit dem 5.11.7-zen (Artix) und dem 5.10.24 (LinuxMint 18.3).

Den RC habe ich nicht getestet.