Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Caramon2
18.03.2021 23:34:09

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.

frostschutz
18.03.2021 13:19:49

ist laut changelog in 5.10.24, 5.11.7 und 5.12-rc3

Caramon2
18.03.2021 10:43:57

> Jan Kara 2021-03-17 17:42:21 UTC
> OK, patch is merged upstream. Closing the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=211167#c31

Wie läuft das jetzt ab?

Der 5.12 wird den vermutlich bekommen, sicherlich auch der 5.10-lts, aber beim 5.11 brauche ich damit wohl nicht mehr damit rechnen, oder?

Caramon2
13.03.2021 18:16:54

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?

frostschutz
11.03.2021 17:36:19

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/536 … rnel.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.

Caramon2
11.03.2021 16:17:40

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-3XDpe … p=drivesdk

Den Rest davon nicht beachten: Damals wusste ich es nicht besser. - Irgendwann werde ich das überarbeiten…

Caramon2
26.02.2021 18:46:46

Kleines Update:

Mit dem 5.11.1-zen (Artix) funktioniert es noch nicht und der C29 schreibt, dass auch QEMU betroffen war/ist:

https://bugzilla.kernel.org/show_bug.cgi?id=211167#c29

Caramon2
17.02.2021 20:06:14

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.

frostschutz
16.02.2021 16:41:41

LVM (issue_discards bei lvreduce) ist davon auch betroffen gewesen, jetzt gibts erstmal einen Revert, mit etwas Glück geht fstrim+ntfs ab 5.10.17 / 5.11.1 dann wieder.

https://bugzilla.kernel.org/show_bug.cgi?id=211167#c20

Caramon2
14.02.2021 14:44:44

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!

frostschutz
13.02.2021 17:53:15

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)

Caramon2
13.02.2021 17:50:08
frostschutz schrieb:

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.

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.

frostschutz
13.02.2021 17:07:33

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.

Caramon2
13.02.2021 16:31:25
stefanhusmann schrieb:

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.

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.

frostschutz
13.02.2021 16:20:03

Die Frage ist dann wo das EBUSY auf einmal herkommt...

Vielleicht ist es das hier:

https://lore.kernel.org/linux-block/202 … k@suse.cz/

https://lore.kernel.org/linux-block/202 … k@suse.cz/

https://github.com/torvalds/linux/commi … 1984f5fe02

Edit: ach lesen müsste man können, das steht ja schon längst im Bugreport, und ich such mir nen Wolf LOL

Fußzeile des Forums

Powered by FluxBB