Wie und womit kann man manuell ein trim einer SSD anstoßen unter NetBSD?

Clas

Well-Known Member
Guten Morgen,

ich habe versucht herauszufinden mit welchen Tool ich unter NetBSD manuell ein Trim für
meine SystemSSD anstoßen kann? Leider bin ich noch nicht fündig geworden.

grüße,
clas
 
Hallo turrican,

Vielen Dank für deine Antwort,
das mit discard trägt man in die fstab ein. Hat damit sozusagen
ein permanentes aufräumen aktiviert. Das möchte ich aber nicht.
Ich möchte das lieber manuell machen oder auch via cron-Job einmal
in der Woche anstoßen können.

Viele Grüße,
clas
 
Ich kann dir gar nicht sagen, wie oft der Treiber das dann machen würde... Müsste man ggf den aktuellen Source vom discard/trim anschauen, was da genau drinsteht.
 
Hallo,
Vielen Dank ich schau mal dann ob ich das herausbekomme kann ob mounten mit discard auch wirklich sofortiges Aufräumen bedeutet oder das irgendwann durchgeführt wird. Vielleicht ja sogar zeitgesteuert wo man die Zeit konfigurieren kann.
 
Hallo Rob,
ja, stimmt schon. Nur ich war das halt so gewohnt. Ich habe so nach einigen Wochen immer mal ein trim
unter VoidLinux ausgeführt. Jetzt werde ichd as mal NetBSD alleine machen lassen. :)
Clas
 
Ich dachte immer, dass neuere SSD's kein softwareseitiges trim mehr benoetigen, sondern dass das hardwareseitig durch die SSD geschieht. Weiss da jemand was genaueres?
 
Ich dachte immer, dass neuere SSD's kein softwareseitiges trim mehr benoetigen, sondern dass das hardwareseitig durch die SSD geschieht.

Softwareseitige Unterstützung des Wear Leveling durch TRIM ist in jedem Fall angeraten. Inzwischen sind die SSDs aber groß und robust genug (samt ausreichend intelligenter Firmware), dass die SSDs bei normaler Nutzung nicht mehr zu Lebzeiten des Rechners verrecken, selbst wenn niemals ein TRIM abgesetzt wird (sie sterben ohne TRIM aber trotzdem früher).

ja, stimmt schon. Nur ich war das halt so gewohnt. Ich habe so nach einigen Wochen immer mal ein trim
unter VoidLinux ausgeführt. Jetzt werde ichd as mal NetBSD alleine machen lassen. :)

Periodic TRIM ist nach wir vor die sichere Voreinstellung. Bei sehr schreiblastiger Nutzung der SSD mit großen Datenmengen kann zwischen TRIM-Läufen der (aus SSD-Sicht) freie Speicher sehr klein werden, was aus Sicht des Wear Leveling nicht optimal ist.

Continuous TRIM hat den Nachteil, dass ein WRITE + TRIM (auf moderner Hardware unwesentlich) länger dauert als nur ein WRITE. Dafür wird das Wear Leveling minimiert.

Ältere SSDs konnten entweder TRIM oder normale Operationen ausführen, nicht beides gleichzeitig, was zu vergleichweise schlechter Performance beim Löschen geführt hat. Noch ältere SSDs hatten teilweise Datenkorruption bei Continuous TRIM.

XFS und BTRFS unter Linux haben inzwischen ein discard=async, was die Vorteile beider Welten vereint und alle Nachteile vermeidet. NetBSD hat das aber meines Wissens noch nicht umgesetzt.
 
wenn sich bei modernen ssds eigentlich der platteneigene Controller um die interne Organisation kümmert, braucht es dann noch ein Kommando bzw eine irgendwie geartete Kommunikation vom OS dazu?
 
Das ist ein gute Frage.

Allerdings stellt sich dann die Frage warum auf anderen System solche Tools noch existieren. Ok, vielleicht für ältere SSDs wo das manuell angestoßen werden musste. Ich verwende in meinen NetBSD-Desktop als SystemSSD eine 1TB SSD von WD. Diese SSD:
Aber im Grunde glaube ich auch nicht mehr wirklich daran dass das noch irgendwelche Auswirkungen negativer Art hat wenn man das nicht manuell
anstoßen kann. Von daher werde ich das einfach mal so lassen wie es jetzt ist. :)
 
wenn sich bei modernen ssds eigentlich der platteneigene Controller um die interne Organisation kümmert, braucht es dann noch ein Kommando bzw eine irgendwie geartete Kommunikation vom OS dazu?
Naja, es hilft dem Controller schon sehr zu wissen, welche Flash-Zellen belegt sind und welche nicht. Der Controller hat ja kein Verständnis von den Daten, die auf der SSD liegen. Er kennt nicht das Dateisystem, dessen interne Strukturen und so weiter. Er sieht nur, ob eine Flash-Zelle belegt ist oder nicht. Ohne einen Mechanismus um Blöcke und damit Flash-Zellen als unbelegt zu markieren, füllt sich aus Sicht des Controllers die SSD nach und nach komplett. An dem Punkt hat der Controller für seine Wear Leveling Algorithmen nur noch den zursätzlichen Platz zur Verfügung, den die SSD physisch größer ist als logisch nach außen kommuniziert. Wie viel das ist, geben die wenigstens Hersteller an, aber selten mehr als ein paar Gigabyte.

Bei modernen SMR-Festplatten ist es übrigens ähnlich. Sie unterstützen TRIM um Wissen darüber zu erhalten, welche Blöcke tatsächlich belegt sind. Das kann die Firmware nutzen, um die SMR-Spuren nicht stumpf durch lesen und anschließendes Überschreiben aktualisieren zu müssen, sondern etwas intelligenter und damit performanter über alle vorhandenen Spuren zu rotieren. Oder die Spuren sogar dynamisch zu allokieren.
 
@Clas

Trim Befehl? Gibt es in der Form unter NetBSD m.A. nicht, "discard" in den Mount-Optionen aber dann ohne "log". Ich fahre meine NetBSD Server seit Jahren ohne Trim, keine Probleme auch beim Löschen und neuen Schreiben - lass es einfach wie bisher!

VG aus LE
Franco
 
Ich hab mal eben einen alten Artikel aus der CT (von 2017) herausgekramt zur Lebensdauer von SSDs. Da wurden SSDs der damals üblichen Größe von 240GB dauerbeschrieben.

Durchschnittlich hatten solche SSDs eine Garantie von 50-80 TB, im Test hatten die Dinger durchschnittlich zwischen 500 und 1000 TB ausgehalten bevor sie starben. Das ganze wurde natürlich ohne TRIM gemacht.

Und ja, die damals vorherschende Technik war schon TLC / MLC. Ich denke also in punkto Haltbarkeit muss man sich da bezüglich TRIM oder nicht TRIM keine Sorgen machen :)

Im Betrieb hatten wir auch über etliche Jahre unsere SSDs in den Workstations ohne TRIM betrieben, da cryptsetup damals das noch nicht unterstützt hat. Wir hatten zwar immer nen kleinen Bereich (ca 10%) der SSD unpartioniert gelassen, damit der Chip intern besser Wearleveln kann, aber denke das hätten wir uns auch sparen können. Auf jeden Fall wurden die SSDs obsolet weil sie zu klein wurden, nicht weil sie kaputt gingen.

Punkto Geschwindigkeit braucht man sich bei modernen SSDs denke ich auch keine Sorgen machen, selbst günstige M2 PCIe 3/4 SSDs haben schon 3 TB/s bzw. 5 TB/s schreiben also da will ich erst mal die Workstation/Desktopanwendung sehen, die das auslastet :)
 
Wir betreuen ja so ca. 900 PCs - früher festplatten und jetzt ssds sind eigentlich das was am seltensten defekt geht, villeicht so 1-2 / Jahr - am häufigsten sind Netzteile gefolgt von Mainboards ia
 
Zurück
Oben