"Mysterium" Trim

  • Interessant ist der Einfluss von TRIM auf das Schreibverhalten, da bei einer SSD ein Block nicht einfach überschrieben werden kann. Kann die SSD mangels Trim die Blöcke nicht vorher freigeben müssen die vor dem Schreiben erst noch gelöscht werden und das bremst natürlich.

    • Apple Mac Studio | M1 Ultra | 64GB RAM | 1TB
    • AMD Ryzen 9 3950X | ASUS Strix X570-I Gaming | 64GB DDR4-3600 CL16 RAM | Corsair MP600 M.2 NVMe | Radeon RX 6900 XT | Phanteks Enthoo Evolv Shift | Custom Loop | MacOS 12 | OpenCore
      Ryzen MacPro | EFI | RadeonSensor | Aureal
  • Ich habe gerade noch diese Analyse zum Trim-Support von vit9696 gefunden. Hier werden auch die Modelle mit fehlerhaftem / fehlerfreien Trim-Support aufgelistet: https://github.com/dortania/bugtracker/issues/192


    EDIT: Es darf gerne jeder seine Erfahrungen in dem issue eintragen, so erhalten wir alle eine "Datenbank" mit gut funktionierenden SSDs

    iMac Pro: Asus Prime Z390-A, i5-9600K, Vega 56, BCM943602cs - OC
    MacBook Pro 13" 2020: Lenovo IdeaPad 5-15IIL05: i7-1065G7, Iris Pro Plus G7, Intel AX201 - OC
    ________________________________

    - Dortania OC Install Guide | Dortania OC ACPI Guide | Dortania OC Post-Install Guide

    - Was ist mein Problem? > Ordentlich beschreiben!

    - Gibt es das schon im Forum? > Suche nutzen

    - Wie kann mir geholfen werden? > Ordentlich beschreiben! Nett sein & Danke sagen!

    Edited once, last by pebbly ().

  • Ich würde mich hier auch mal in die Diskussion einhängen. Ich habe eine Samsung 870 QVO mit 8TB in einem 2,5 Zoll-Gehäuse von ICY Box mit USB-C 3.1 (Gen2). UASP wird wohl auch unterstützt. https://www.amazon.de/gp/produ…h_asin_image?ie=UTF8&th=1


    Seit ich die Platte mal an meinem Macbook Pro 2018 mit Monterey hängen hatte, spinnen einige meiner BRAW-files. Man sieht Artefakte und manche Dateien sind überhaupt nicht mehr abspielbar, nun auch auf meinem Hackintosh mit Big Sur.


    Kann das an der fehlenden Trim-Unterstützung liegen? Meine Boot-SSD ist per NVMExpress eingebunden, da steht auch "Trim Support: Yes", bei den Platten über USB 3.1 steht davon nichts. Sollte da nicht auch der Trim Support aktiviert sein? Wenn ja, wie mache ich das?

  • Huitzilopochtli


    Kannst ja mal TRIM in der config.plist eintragen.



    Ansonsten sudo trimforce enable imTerminal eingeben. Musst du dann aber nach einem Update wieder machen.

  • Hängt auch vom USB Controller im Gehäuse ab, nur wenn er die entsprechenden Protokolle unterstützt funktioniert TRIM über USB.

    • Apple Mac Studio | M1 Ultra | 64GB RAM | 1TB
    • AMD Ryzen 9 3950X | ASUS Strix X570-I Gaming | 64GB DDR4-3600 CL16 RAM | Corsair MP600 M.2 NVMe | Radeon RX 6900 XT | Phanteks Enthoo Evolv Shift | Custom Loop | MacOS 12 | OpenCore
      Ryzen MacPro | EFI | RadeonSensor | Aureal
  • Ich hatte eine Vermutung bzgl. Monterey und der sonst nicht normal Trim-fähigen Platten und wie es aussieht, funktioniert das jetzt.

    Ich hab mit SetApfsTrimTimeout -1 gebootet, keine verlängerte Bootzeit gehabt und das hier mit log show --debug --last boot --predicate "processID == 0" | grep spaceman ausgelesen:



    Mit Big Sur und den Einstellungen wurde mir die Platte gar nicht erst in dem log angezeigt, glaub ich mich zu erinnern.

    Sie heißt auch noch BigSur, weil es da wieder drauf kommt, aber momentan ist dort eine kleine Monterey installation darauf.


    edit: Ja, mit Big Sur kommt taucht die Platte im log gar nicht erst auf.

  • Guckux


    Ich führe gerade eine interessante Konversation mit "meinem Kölner Guru", Dipl. Physiker, Kernel-Entwickler und ITler... ;)


    Er befürwortet für die Performance UND Lebensdauer verlängernd, daß man SSDs nicht voll nutzt (also einen Bereich leer lässt, von 1000GB nur 900GB in partitionen zur Verfügung stellt.

    Hintergrund:

    Hierdurch werden sehr viele "leere" Blöcke, somit kann das umkopieren von teil-gefüllten Blöcken in leere (Garbage collection genannt) optimiert(er) ablaufen. Während des Umkopierens sind diese also "doppelt" vorhanden.

    -> Je weniger leere Blöcke existieren, umso häufiger muss das umkopieren stattfinden -> mehr Schreib-/Lesezyklen auf den Zellen.

    Jedes Umkopieren kostet einen Löschzyklus -> Reduzierung der Lebensdauer.


    Hat man also viele leere Blöcke (nicht verteilt durch Partitionen), braucht die Garbage collection seltener angestossen zu werden -> dadurch weniger Garbage Collections -> weniger Löschzyklen -> längere Lebensdauer.


    Ich versuche gerade für mich einen weiteren logischen Zusammenhang zur "Trim-Zeit" zu finden :D


    Für mich klingt das sehr logisch und nachvollziehbar

    Bye

    Stefan


    Edited once, last by guckux: Rechtschreibung ().

  • Ist für mich auch sehr schlüssig….


    Außerdem passt es zu meiner Erfahrung, dass die Performance bei minimalen freien Speicher eklatant einbricht ……

  • Dieser Ansatz hängt m.E. stark davon ab, wie die phys. Blöcke ("Sektoren") tatsächlich logisch - im Sinne von Partition und weiter dann im Dateisystem - verwaltet werden.

    Kommend von der Magnetscheibe der Diskette war das eine 1:1 Beziehung zwischen logischem Sektor und phys. Sektor. Bei HDDs kam irgendwann Sector Relocation dazu. Hier wird ein defekter Sektor durch einen anderen Sektor ersetzt, ohne dass die logische Partition oder das Dateisystem kaputt geht. D.h. logische Sicht und phys. Sicht auf "Blöcke" ist unterschiedlich. Bekanntweise macht bei SSDs das koventionelle Konzept von Spuren/Sektoren ja keinen Sinn mehr. Und jetzt bleibt die Frage, ob bei einer SSD für die Performance es einen Unterschied zwischen leeren Blöcken gibt, die einer Partition oder keiner Partition zugewiesen sind.


    Für die Lebensdauer halte ich das für nachvollziehbar. Auch wenn SSDs bereits Spare-Blocks mitbringen.


    In Bezug auf Performance ist der Gedanke deines "Gurus" an sich Schlüssig, ob das aber tatsächlich so "wirkt" .....

    Wobei das alles bezogen auf den Füllstand betrachtet werden muss.

  • korrekt die Ausführung zur Magnetplatte... dort gibt es entsprechende reserved Blocks, welche bei defekten Sektoren "einspringen" (auch bei einer SSD gibt es entsprechende/vergleichbare reserved Blocks)


    Und ja, bei einer SSD ist es unter Mengenlehre zu verstehen, da gibt es keine Spuren oder Blocknummerierungen wie "früher".

    Habe ich die Menge 100 und partitioniere davon für das System die Menge 90, dann wird 90 genutzt. Sind in den 90 keine freien Blöcke mehr, kann die SSD entsprechende freien Blöcke von 100-90 verwenden. Achso, bevor jemand sagt, dann ist doch das filesystem in den 90 voll - nicht unbedingt, weil die Blöcke teils zB zu 1/4 oder 2/4 nur "gefüllt" sind. Wenn dann "der Schwellwert" (dürfte eine Firmware Definition sein) überschritten wird, geht das System her und kopiert die ganzen teil gefüllten Blöcke in leere um zu gefüllten 4/4. Wenn diese Kopiervorgang beendet ist, werden die teilgefüllten gelöscht.

    Nicht tangieren tut dies alles der Performance Verlust im filesystem 90, wenn dieses "vollläuft", das ist einfach ein Defizit von filesystemen... ;)

    Bye

    Stefan


    Edited once, last by guckux ().

  • Ich bin jetzt verwirrt. Was ist der Unterschied zwischen simplen Over Provisioning und dem was ihr da beschreibt? Kann man doch mit Magican bei jeder Samsung Platte zum Beispiel ändern/konfigurieren?

  • MPC561 Es geht nicht um overprovisioning, sondern um die Theorie, dass eine z.b. nur zu 90% partitionierte SSD (10% bleiben frei) förderlich für Performance/Lebensdauer sei.


    Meine Meinung: das mit der Lebensdauer hab ich gekauft und afaik schon mal in der ct gelesen. Das mit der Performance ... da bin ich noch unschlüssig.

  • Ja aber genau das ist Over Provisioning. Genau da weisst Du eine gewisse Kapazität zusätzlich dem normalen Overprovisioning Bereich (ca. 7%) zu, den die Platte sowieso hat, um Performance und Lebensdauer zu verbessern. Wie gesagt bei Samsung via dem Magican Tool konfigurierbar.