OpenCore Sammelthread (Hilfe und Diskussion)

Mit der 0 ist es deaktiviert. Eins von beiden geht nur würd ich sagen

https://github.com/acidanthera…522e349acdede22de125d3157

Zitat von hackmac004

DerTschnig Ja, find ich auch gut, dass es die Funktion wieder gibt. Trim wird dann aber nicht ausgeführt da komplett deaktiviert, was nach einer Weile zu Geschwindigkeitseinbußen führt, wenn viele Daten geschrieben und gelöscht wurden. Dann kann man den wert aber für einen boot auf -1 stellen und dann wird mal eben getrimmt.

Hiermit kannst du die Trimzeiten im terminal auslesen.

log show --debug --last boot --predicate "processID == 0" | grep spaceman

trim wird aber als aktiv angezeigt

Es wird gesagt, das es unterstützt ist und das ist es auch, aber mit einigen Controllern, wie bei den Samsung NVMEs, funktioniert es nicht gut. Deswegen die langen bootzeiten. Um die zu umgehen muss es beim Start deaktiviert werden. Man erkennt die Deaktivierung auch wenn man den spaceman Befehl eingibt.

0,0000 ist in meinen Augen deaktiviert.

Ich kann das Problem mit Trim nicht nachvollziehen, schon garnicht auf den Samsung NVMes.

Nutze eben deswegen keine Samsung, Ausgabe auf meinem System mit Trim -1 :

hackmac004 die ausgabe bedeute allerdings auch das garkein trim stattgefunden hat

So siehts bei mir aus )danke für dem Terminal Befehl):

iMac:~ andreas$ log show --debug --last boot --predicate "processID == 0" | grep spaceman_scan_free_blocks | grep "trims took"

2022-02-12 08:11:00.460800+0100 0x2de Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk5 scan took 1.278090 s, trims took 1.177745 s

2022-02-12 08:11:06.884811+0100 0x810 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk11 scan took 0.285549 s, trims took 0.158170 s

2022-02-12 08:11:06.972138+0100 0x83f Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk6 scan took 0.174345 s, trims took 0.131927 s

2022-02-12 08:11:09.247162+0100 0x830 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk9 scan took 0.323745 s, trims took 0.001075 s

iMac:~ andreas$

Diese Trim Zeiten im niederen, einstelligen Sek Bereich stören ja echt nicht...

mitchde selbst wenn es nicht einstellig ist ist das verschmerzbar. platte ist verschlüsselt mit FV. da kann auch 2-3 sek dauern. gibt schlimmeres: installier mal SCCM....

ozw00d Das ist klar, deswegen hab ich weiter vorne ja auch das hier geschrieben. OpenCore Sammelthread (Hilfe und Diskussion)

Ich hatte das mit BigSur die ganze Zeit deaktiviert und tatsächlich ist die Platte langsamer geworden. Als ich ein mal Trim durchlafen ließ, hatte sie wieder die übliche Geschwindigkeit. Ist nicht optimal, aber ein workaround für die die sich keine neue Platte deswegen extra zulegen möchten.

hackmac004 pfft wozu ne neue platte wenns läuft? stimme dir da zu, macht keinen sinn. Solang das wearing Leven im grünen Bereich bleibt, tausch ich da auch nie was aus.

Zitat von hackmac004

Mit der 0 ist es deaktiviert. Eins von beiden geht nur würd ich sagen

https://github.com/acidanthera…522e349acdede22de125d3157

Das verstehe ich nicht. Nur mit diesenn Einstellungen bootet der PC OC 0.7.9 schnell und TRIM wird in den Systeminformationen/SATA als aktiviert amgezeigt. Mit OC 0.7.8 bei gleicher Einstellung dauert der Boot mindestens doppelt so lange.

SetApfsTrimTimeout 0

ThirdPartyDrives YES

TRIM-Unterstützung: Ja

Bootzeit schnell

Bei dir läuft kein trim user232. Probier mal eine -1.

Das hatte ich auch zuvor schon ausprobiert gehabt

SetApfsTrimTimeout -1

ThirdPartyDrives YES

TRIM-Unterstützung: Ja

Bootzeit langsam

user232 oh weh das sind wirklich heftige trim Zeiten. Mit 0 wird das Ganze lediglich deaktiviert. Bedeutet das trim im os zwar unterstützt wird, jedoch nicht losrennt. Was für eine ssd/nvme hast du denn?

Ich habe eine SanDisk Ultra 3D SATA Festplatte. Mit meiner alten Samsung 860 QVO SATA hab ich diese lange Bootzeiten nicht. Heißt es, dass ich ThirdPartyDrives wieder auf NO setzen soll, da YES ja nicht wirklich funktioniert, auch wenn es in den Systeminformationen als positiv quittiert wird?

probier das setting mal ThirdPartyDrives=NO. Ich hab das bisher bei keiner meiner SSD's benutzt. Da war auch schon zum testen mal ne wirklich billige (so ein Chinateil) dabei, ging auch da ohne Probleme. Zur not trim via

aktivieren.

Habe seit einigen Wochen das Problem, das der Rechner bzw. Monterey aus dem Sleep mit einem Warmstart des Rechners bootet.

Ob das jetzt mit dem "Sleep" was damit zu tun hat... keine Ahnung.

Was mir aufgefallen ist, das der Rechner gefühlt ca. 10 mal bootet und beim 11. mal dann mir die Meldung anzeigt dass das "Bios has been reset. Please re-config your Bios setup items if needed" ,

gesagt getan, nach Prüfung der Bios Einstellungen wurde aber nichts resetet bzw.

Heute wieder das Problem, aber diesmal habe ich das 10.... malige booten des Rechners abgewürgt, indem ich den Rechner ausgeschaltet habe und wieder ein, hier lief der Bootprozess des Bios durch und es wurde keinerlei Meldung des Bios angezeigt. Monterey konnte gestartet werden.

Jemand ne Idee woran das liegen könnte?

Gruss

Schmalen

schmalen eventuell könnte die CMOS Batterie nicht mehr genug Saft haben, Ähnliches hatte ich auch.

Mal das einfachste zuerst prüfen, multimeter anschmeissen und messen.

ozw00d leider bewirkt der Terminalbefehl gleiches wie zuvor schon geschrieben. Ich lass nun TRIM weg.

LÖSUNG für das TRIM Problem mit NVME:

Klappt bei mir (auch ohne NVRAM reset):

Those who are suffering to slow boot issues in Monterey due to NVMe please read this post carefully:

For fixing that slow boot issue you can follow the following steps:

Update OC to 0.7.9 (Oc 0.7.8 or lowers does not work with the fix)

In config.plist go to kernel > Quirks > SetApfsTrimTimeout

set the value from -1 to 0

Save

Reboot and reset Nvram.

It should fix your issue.

N.B:

This fix works only with OC 0.7.9 (Till today's date 12-02-2022)

Tested with latest Monterey stable 12.2.1 (Till today's date 12-02-2022)

user_232 Ich habe bei meinem Setup mal die Parameter SetApfsTrimTimeout und ThirdPartyDrives variiert und die Auswirkungen auf Trim abgefragt. Ich habe eine NVMe und 3 Sata SSDs.

Folgendes Ergebnis:

SetApfsTrimTimeout / ThirdPartyDrives / trim?

0 / true / trim NVMe und Sata

0 / false / trim nur NVMe

-1 / false / trim keine

-1 / true / trim nur Sata

Die Trimzeit für die NVMe liegt bei 59s. Es handelt sich dabei um eine Samsung EVO 970. Die Trimzeiten der Sata SSDs gehen im Rauschen unter.

spacepilot3000: Abschalten hilft bei einigen Sachen immer - ob das aber "die Lösunge" ist?

Zitat aus der Differences.pdf:

"On macOS 12+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled

when the timeout value is set to 0."