"Mysterium" Trim

Ist tatsächlich casesensitive. Nach Änderung auf "EnableTRIM" steht bei allen SATA-SSDs "TRIM-Unterstützung" auf "Ja"

Ein Dankeschön an dieser Stelle an Leggalucci

log show --predicate "processID == 0" | grep trims > ~/Desktop/trim2.txt

2021-04-18 17:53:37.278773+0200 0x6de Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk12 scan took 0.004937 s, trims took 0.000000 s

2021-04-18 17:53:38.017991+0200 0x7fe Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk14 scan took 0.209760 s, trims took 0.000000 s

2021-04-18 17:53:38.863330+0200 0x6b4 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk17 scan took 1.641537 s, trims took 0.000000 s

2021-04-18 17:53:41.475446+0200 0x879 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk15 scan took 3.583681 s, trims took 0.000000 s

2021-04-19 11:58:58.625748+0200 0x6ea Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk13 scan took 0.005266 s, trims took 0.000000 s

2021-04-19 11:58:59.350281+0200 0x854 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk14 scan took 0.221365 s, trims took 0.000000 s

2021-04-19 11:59:00.105448+0200 0x70e Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk16 scan took 1.453629 s, trims took 0.000000 s

2021-04-19 11:59:02.763183+0200 0x88b Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk15 scan took 3.482226 s, trims took 0.000000 s

2021-04-19 12:42:21.515018+0200 0x6df Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk14 scan took 0.957011 s, trims took 0.951599 s

2021-04-19 12:42:21.515024+0200 0x6df Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3383: disk14 121481805 blocks trimmed in 11 extents (86509 us/trim, 11 trims/s)

2021-04-19 12:42:22.046791+0200 0x6af Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk17 scan took 1.544321 s, trims took 0.003185 s

2021-04-19 12:42:22.046802+0200 0x6af Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3383: disk17 141574990 blocks trimmed in 48882 extents (0 us/trim, 15347566 trims/s)

2021-04-19 12:42:22.203770+0200 0x7e9 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk15 scan took 1.177838 s, trims took 1.004441 s

2021-04-19 12:42:22.203775+0200 0x7e9 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3383: disk15 30244781 blocks trimmed in 3415 extents (294 us/trim, 3399 trims/s)

2021-04-19 12:42:24.692325+0200 0x864 Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3367: disk16 scan took 3.504203 s, trims took 0.000000 s

Mal herzlichen Dank an alle Diskussionsteilnehmer und so...

Mir unklar ist, wieso sich dergleichen auf die Bootzeit auswirkt. TRIM ist ein SATA/SAS command für SSDs, welches normalerweise aktiv durch das filesystem ausgeführt wird.

Also, ich lösche Dateien, dann hat das fs einen "TRIM-Befehl" zu schicken, welcher der SSD (egal ob SATA oder m.2/nvme) mitteilt, die Blöcke x, y etc. sind gelöscht worden, lösche sie in Deinen Zellen und das zur Laufzeit...

Ich kann das jetzt schlecht "kreuzverifizieren", meinen Server (FreeBSD) reboote ich höchstens 2mal im Jahr, die Workstation habe ich jetzt erst auf SSD umgestellt, da muss ich auch erstmal schauen, was mir mein BSD erzählen kann...

Normalerweise würde ich erwarten vom APFS, daß es zur Laufzeit der SSD via TRIM mitteilt, daß Blöcke nicht mehr genutzt werden und nicht erst beim nächsten Neustart...

Ich lese hier mit, da ich gerade mit TRIM Problemen bei originalen Macs mit nachgerüsteten SSDs hatte und ggf. neue Erkenntnisse erhoffe.

Allerdings wundert mich immer, wenn an solchen Optionen herum gespielt wird, nur um die Startzeit des Systems zu verbessern. Wenn es darum geht, Probleme zu lösen, gerne. Aber nur damit das System 10 Sekunden schneller startet? Mein Workflow sieht ähnlich aus, wie der von bluebyte (Rechner einschalten, Kaffee holen, anmelden). Das verstehe ich nicht. Vielleicht bin ich aber auch schon viel zu alt, um das zu verstehen. Wie hieß es früher immer: In der Ruhe liegt die Kraft!

Ich kann bluebyte und atl kurz beipflichten.
wir leben in einer Welt wo alles auf Geschwindigkeit getrimmt wird. Jeder davon ausgeht das das so sein muss.
aus einer anderen Perspektive betrachtet stelle ich mir immer die Frage „muss das sein?“.
unsere Zeit ist kostbar und kurz auf dieser Erde.
sollten wir uns da nicht eher öfters ermutigen ab und zu etwas zu entschleunigen?

Ich mags für mich chillig , kenne mich Zeiten in denen ein Rechner quasi erst mal warm laufen musste.
das ist lange vorbei.
die Technik von heute hat genug power, da muss ich nicht mit Hektik meinen Rechner einschalten. Ob nun 5,10 oder 30 Sekunden für den Start. Juckt mich nicht. In der Zeit Nuckel ich an meiner e-ziggi mache mir nen frischen Kaffee.

Vielleicht werde ich auch alt wer weiß.

Ich habe in meinen Anfangszeiten viel an irgendwelchen Stellschrauben gespielt, und in den Jahrzehnten lernen dürfen, daß die DEFAULT-Einstellungen idR immer die Besten sind.

Mittlerweile bin ich viel mit Oracle-DBs unterwegs, und wer da nicht genau weiß, was er mit den 4987 (fiktiver Wert, es sind aber viiiiele) Stellschrauben bewirken kann (und viele sind komplex, haben also Abhängigkeiten untereinander) sollte die Finger davon lassen.

Viel sinnvoller ist es resourcenschonend zu arbeiten, weniger ist mehr!

Weniger -> je weniger Komplexität ich in ein System hineinbringe, desto einfacher ist die Handhabung bis inclusive. Update.

Resourcenschonend: einfach nur ne Shell verwenden, damit lassen sich die meisten Aufgaben lösen, perl mag mächtig sein, lädt aber im default zB erstmal viele MBs nach, ggfs noch ein paar weitere Module (weil die es so schön lösen), am Schluss habe ich für ne einfache Aufgabe zig MBs zu laden mit Haufen IO und MBs bis GBs an Speicherresourcen verbraten.

Das script löst die Aufgabe in 4.38s und das perl braucht dann den 10-100 fachen Arbeitsspeicher und 11.89s...

Ich glaube, wir reden hier aneinander vorbei. Trim = ja. Und der hohe Wert bei SetApfsTrimTimeout ist keine „Spielerei“ sondern dient dazu herauszufinden, ob Trim bei der eingesetzten NVME kaputt ist. So war es bei mir, die SSD habe ich mittlerweile durch eine andere ersetzt.

Bzgl der Werte in SetApfsTrimTimeout: In der OpenCore Config Referenz steht, dass macOS einen Defaultwerte von "9,999999 sec" hat und danach den Trimvorgang stoppt. Weiterhin wird beschrieben, dass _manche_ Samsung Controller anscheinend relativ langsam seien und die nötigen Trim Commands nicht schnell genug abarbeiten und es wird die Befürchtung geäussert, wenn also der langsame Controller nicht alle Trims innerhalb der 9.999999 Sekunden schafft, immer wieder nur die kürzlich gelöschten blocks trimmt: "...trims the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks.". Somit wäre Trim in diesem Fall funktionslos und würde zu höherem Verschleiß führen (siehe Text in der OPenCore Configuration.pdf).

Mit SetApfsTrimTimeout = -1 (==4294967295) setzt man anscheinend den Timeout auf den längsmöglichen Wert. Bei meiner aktuellen 870EVO ist der Trim nach ca 1,7sec durch. Bei meiner alten 840Pro, die lange ohne Trim lief, hat das 23sec gebraucht. Mein meinem MBP2020 mit NVME ist das in 1,x sec durch.

Ich vermute dass in meinem Fall bei der Samsung 840Pro (die kam afaik 2012 auf den Markt) halt ein langsamer Controller hier die Rolle spielt und dass meine neue 870EVO hier besser ist und somit die Bootzeiten mit Timeout=-1 Timeout=4294967295 sich nicht sonderlich verlängern.

Warum ist -1 = 4294967295? Wenn -1 eingetragen ist, wird gar nicht gepatcht.

Hab gerade versucht ohne den sudo im Terminal Eintrag den TRIM via Clover 5070 auf Catalina 15.7 zu aktivieren mit diesem Eintrag Siege Bild.

leider ohne Erfolg woran kann das liegen?

nvram reset hab ich gemacht!

Oder geht es nur über den Terminal Befehl?

Wenn der Haken bei "Disabled" gesetzt ist, wird der Patch nicht ausgeführt.

al6042

Stimmt das war es! 😁

Jetzt hat es geklappt 👍

die boot Zeit war aber identisch gleich zu trim disabled hab jetzt kein unterschied gemerkt!

Kann es sein? Sollte doch eigentlich Länge dauern oder nicht?

Woher weißt ich das es wirklich geklappt hat obwohl TRIM auf ja steht?

auf dem T470 war zwar ein Unterschied zu sehen, aber nicht wirklich überwältigend. Insbsondere beim Schreiben rührt sich nichts. T470 kann eh nur 2 von 4 Lanes benutzen. Deshalb fährt die Möhre ohnehin nur mit halber Kraft.

Ohne TRIM

mit TRIM

Warum schaut ihr immer wieder auf die Zeit, die der Rechner für den Start braucht? Wer ständig die Stoppuhr in der Hand hält oder andauernd Benchmarks startet, der hat das mit dem TRIM immer noch nicht verstanden.

Es geht in erster Linie nicht um Geschwindigkeit sondern um Lebenszeit.

Erdenwind Inc.

es geht doch grad garnicht um die boot Zeiten sonder ob es jetzt überhaupt funktioniert auch wenn Trim auf ja steht! und wenn sich die boot Zeiten nicht geändert haben, kann man auch denken das es nicht funzzzt.

ausserdem kann man sich ein Cappuccino auch dann machen wenn der Rechner schon hoch gefahren ist!

Zitat von Harper Lewis

Warum ist -1 = 4294967295? Wenn -1 eingetragen ist, wird gar nicht gepatcht.

Ja, stimmt, sieht so aus, dass im OC Code im IF ein Integer und kein Unsigned benutzt wird. Der Wert, wenn er >=0 ist, wird dann beim Setzen als UINT interpretiert

4294967295 == 0xFFFFFFFF und das ist als Integer INT == -1, jedoch 4294967295 als UINT.

Ist aber auch Sinnvoll das mit -1 zu deaktivieren zu können.

Danke für den Hinweis.

Zitat von bluebyte

Warum schaut ihr immer wieder auf die Zeit, die der Rechner für den Start braucht? Wer ständig die Stoppuhr in der Hand hält oder andauernd Benchmarks startet, der hat das mit dem TRIM immer noch nicht verstanden.

Es geht in erster Linie nicht um Geschwindigkeit sondern um Lebenszeit.

meintest Du das hier? Was sagen die Werte aus, 100% Lebenszeit meine ich nicht.