SSD trim auf unpartitionierte Bereiche

[bigCrash]

Hallo Forum ,

folgendes:
Ich habe auf meinem Laptop ein Debian am laufen. Das ganze hat mehrere Installationen gebraucht, da immer irgendwas nicht geklappt hat und ich letzenendes Testing nutzen musste....Was aber nun läuft.

In dem Laptop ist eine SSD (850 pro) verbaut und ich habe bei jeder Installation etwa 20% unpartitioniert gelassen, eben als OP. Durch die mehrfache Partitionierung und das mehrfache Beschreiben kann ich aber ja davon ausgehen, dass dieser unpartitionierte Bereich doch gelöschte "Zellen" beinhaltet.

Die Frage ist, inwiefern dieser dann noch komplett als OP funktioniert. TRIM funktioniert ja nur innerhalb des Dateisystems oder? Erkennt der SSD-Controller den nicht patitionierten Bereich dann automatisch als frei?

Grüße
bigCrash

 

[Holt]

Der nicht partitioniere Bereich der SSD ist dann für den Controller frei, wenn er nie beschrieben oder beschrieben und getrimmt wurde. Was jetzt bei Deiner SSD der Fall ist, kannst nur Du wissen, wenn überhaupt. Ein Tool welche den nicht partitionierten Bereich trimmt, kenne ich nicht. Aber wenn TRIM funktioniert, braucht man eigentlich kein OP einzurichten, schon gar nicht gleich 20%, aber das ist Deine Sache. Im Notfall musst Du eben eine Secure Erease durchführend und die SSD noch einmal neu einrichten, damit die LBAs im OP Bereich garantiert für den Controller auch als leer erkannt werden.

 

[Peter123x]

Och... das kann man auch selbst finden.
https://www.google.de/search?q=linux+ssd+trim+manuell
https://www.bitblokes.de/2013/07/ss...fstrim-und-cronjob-auch-ohne-anacron-machbar/
TRIM

Auf dem Notebook läuft eOS. Ich hatte das mal irgendwie manuell getrimmt. Das ist nicht wichtig. Es gibt ja noch die Garbage Collection. Den leeren Bereich kann man ja vorübergehend partitionieren. Wo ist da das geringste Problem...

 

[pajaa]

TRIM geht auf die beschriebenen Bereiche, egal wo die Daten liegen, denn das weiß das jeweilige OS, das mittels eines TRIM-Kommandos dem SSD-Controller mitteilt, welche LBAs es gerade gelöscht hast auch nicht. Der Controller guckt in seiner Zuordnungstabelle nach und löscht dann die entsprechenden Blöcke.

 

[Holt]

pajaa, was Du beschreibst ist das Online TRIM, was bei Windows mit fsutil behavior set DisableDeleteNotify 0 und bei Linux über die Option discard beim Mounten (z.B. in der /etc/fstab) aktiviert wird.

Es gibt auch Offline TRIM, das geht unter Linux mit fstrim und bei Windows ab Win8 mit der SSD Optimierung. Das ist auch, was einige SSD Toolboxen als SSD Optimierung anbieten. Dabei werden alle LBAs die vom Filesystem als nicht belegt gemeldet sind dann getrimmt. Das geht aber nicht für Bereiche die zu keinem Filesystem gehören, da ist mir keine Methode bekannt, vielleicht können das ja einzelne SSD Toolboxen, aber das müsste man ausprobieren ob das wirklich so ist, denn wenn man das implementiert muss man aufpassen keine Metadaten z.B. für die Partitionierung zu zerstören, die ja z.B. am Anfang der Platte auch außerhalb der Partitionen und damit außerhalb des Filesystems liegen und z.B. GPT legt am Ende der Platte auch noch mal Backups in Form des Secondary GPT table und des Secondary GPT Header an. Wenn man also nicht partitionierte Bereiche trimmen wollte, müsste man höllisch aufpassen.

Am einfachste dürfte es sein eine Partition anzulegen und diese mit fstrim zu trimmen und dann nicht in die etc/fstab einzutragen, damit sie nicht gemountet wird.

 

[pajaa]

Richtig, ich beschreibe etwas, was jedes moderne Betriebssystem von sich aus tut und keinerlei Eingriff des Users erfordert. Offline TRIM, so wie du es nennst und beschreibst, habe ich seit etwa 5 Jahren nicht mehr durchgeführt. Ich sehe auch keinen Grund dazu.
Dann muss man auch keine Partition anlegen, die man nicht will und auch sonst nichts tun.

Auf der anderen Seite sehe ich keinen Grund, 20% der SSD unpartioniert zu lassen, denn ob ich nun 20% frei oder unpartitioniert lasse hat nur den Unterschied, daß letzteres unflexibel ist

 

[Peter123x]

Ob die Acronisse der letzten Jahre vor dem Restore ein TRIM senden? Ich mache das vorsichtshalber immer manuell - ist doch wirklich keine Arbeit.

 

[bigCrash]

Hallo,
erstmal Danke für die ganzen Antworten....

@Holt: Danke für den Hinweis auf Secure Erease! ....und danke für die Idee mit der nicht gemounteten Partition anstelle des unpartitionierten Bereichs Gefällt mir:P
@Peter123x: mir war klar wie manueller Trim funktioniert, allerdings eben nicht ob der auch für unpartitionierte Bereiche gilt....wie ich jetzt weiß: nicht. :/
@alle:

Ich hab in der Tat online Trim nicht eingetragen. Darüber hinaus habe ich die 20% OP gewählt, weil Samsung es so empfohlen hat, ich die Argumentation nachvollziehen konnte und ich die 20% nicht brauche....

Danke und Grüße
bigCrash

 

[Gubb3L]

Wo hat Samsung das denn empfohlen ? Wäre mir aktuell neu und ich sehe dazu auch keinen wirklichen Grund. Meine SSD im Desktop ist seit anfang an nicht pfleglich behandelt worden und wurde teils da downloadplatte sehr stark beschrieben und das immer bis zum limit. Teils ist sie Tage oder Wochen bis auf 1-3Gb voll und trotzdem liefert sie (gerade extra nochmal getestet) die gleichen Leistungswerte wie zu beginn und auch ein erhöhter verschleiß ist nicht ersichtlich.

 

[Holt]

Offline TRIM, so wie du es nennst und beschreibst,

Die Begriffe habe ich mir nicht ausgedacht:

If desirable, enable the "discard" filesystem options for automatic/online TRIM.
...
Alternative to setting the "discard" options is to set up an offline-trim cronjob that runs time fstrim -v (or mdtrim) on the ssd mountpoints periodically.

Man findet statt Offline TRIM auch oft die Bezeichnung Batched Discard :

Linux unterstützt zwei Arten des Discard (nähere Details in der nachfolgenden Tabelle):

* Batched Discard – Der Befehl fstrim /mnt/point/ weist das Dateisystem an, ungenutzte Bereiche zu suchen und diese dem Controller der SSD zu melden. Dieser Befehl muss sporadisch und manuell vom Anwender ausgeführt werden.
* Online Discard – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden. Diese Funktion ist von Haus aus deaktiviert und muss vom Anwender in /etc/fstab mit der Option discard eingeschaltet werden.

Discard ist aber sehr Linux spezifisch, weshalb ich bevorzuge die Begriffe Online und Offline TRIM zu verwenden, auch wenn das TRIM selbst ja das gleiche ist, der Unterschied ist woher die TRIM Befehle kommen und wie die LBAs ermittelt werden.

Ich sehe auch keinen Grund dazu.

Windows 7 konnte nur das Online TRIM und erst mit Win8 hat Microsoft das Offline TRIM in der Form der SSD Optimierung (der Begriff ist leicht mit den OS Optimierungen zu verwechseln, weshalb ich den nicht mag) eingeführt, was sicher seine Gründe hatte. Immerhin habe ich auch schon erlebt, dass sich bei Leute im Forum bei deren Win7 TRIM funktioniert hat die Schreibrate der SSD nach einem Offline TRIM besser wurde. Das macht eigentlich keinen Sinn, weil ja jede unbelegte LBA schon getrimmt worden sein sollte.

Erklären kann man es sich also nur, wenn der Controller das eine oder andere TRIM nicht ausgeführt hat und wenn man überlegt, dass er ja beim gleichzeitig vorhandenen Schreibbefehlen auch noch prüfen muss, ob diese auf die gleichen LBAs gehen, dann könnte ich mir schon vorstellen, dass die FW Programmierer da u.U. mal einfach einen TRIM Befehl ignorieren statt Datenverlust zu riskieren, wenn sie die eben geschriebenen Daten sofort wieder trimmen, nur weil die Reihenfolge der Befehle durcheinander gekommen ist. Bei Crucials m500 gab es da ja unter Linux solche Probleme. Aber das ist eben Spekulation, es sollte theoretisch keinen Sinn machen ein Offline TRIM zu machen, wenn schon immer Online TRIM aktiv war, praktisch tut es aber offenbar zuweilen doch.

Auf der anderen Seite sehe ich keinen Grund, 20% der SSD unpartioniert zu lassen, denn ob ich nun 20% frei oder unpartitioniert lasse hat nur den Unterschied, daß letzteres unflexibel ist

Das sehe ich auch so und habe es ja auch in #2 geschrieben, nur hat bigCrash ja eben danach gefragt, wie es die LBAs in diesem nicht partitionierten Bereich trimmen kann, die er als OP-Area frei halten will. Das macht natürlich nur Sinn, wenn diese LBAs aus Sicht des Controller nicht mit gültigen Daten belegt sind. Gültig sind eben alle Daten die einmal geschrieben und nie wieder überschrieben oder getrimmt wurden.

 

[smutbert]

zur Eingangsfrage noch:

mit hdparm lassen sich einfach Bereiche auf der SSD „trimmen“ - ganz unabhängig von Partitionen und Dateisystemen, dazu zitiere ich einmal aus der Manpage von hdparm:

[…]
--trim-sector-ranges
  For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT
  USE THIS OPTION!! Tells the drive firmware to discard unneeded
  data sectors, destroying any data that may have been present
  within them.    This makes those sectors available for immediate
  use by the firmware's garbage collection mechanism, to improve
  scheduling for wear-leveling of the flash media. This option
  expects one or more sector range pairs immediately after the
  option: an LBA starting address, a colon, and a sector count
  (max 65535), with no intervening spaces. EXCEPTIONALLY DANGER-
  OUS. DO NOT USE THIS OPTION!!
  E.g. hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz
[…]

Etwas unpraktisch ist dabei, dass man sich erstens einmal sicher sein muss, dass man sich mit den Sektoren nicht verrechnet/verzählt damit man nicht irrtümlich einen Teil eines Dateisystems „trimmt“ und zweitens ist auch noch nie Maximalgröße des auf einmal trimmbaren Bereiches lästig, weil man den Befehl uU sehr oft ausführen muss. Sinnvollerweise müsste man hdparm dann in einer Schleife ausführen lassen, was bedeutet, dass man noch einmal mehr aufpassen muss…
…aber das mit dem höllisch aufpassen hat ja bereits Holt geschrieben!
(am sichersten ist es dann vermutlich noch eine leere Partition anzulegen, ev sogar ohne Dateisystem, dann kann man sich Start- und Endsektor mit beliebigen Partitionierungsprogrammen wie gdisk, fdisk, parted, gparted,… anzeigen lassen und zum trimmen heranziehen)

Wenn es einfach nur um das trimmen eines kompletten Geräts geht, finde ich den security erase etwas unpraktisch, weil man dazu afaik zumindest vorrübergehend ein Paßwort setzen muss. Einfacher geht es mit blkdiscard aus dem Paket util-linux (leider allerdings erst in der Version in experimental enthalten), das genau das macht.


Sonst kann man das auch mit dem Formatieren erledigen. btrfs (mkfs.btrfs) kennt die Option -K/--nodiscard — in den Standardeinstellungen wird also meines Wissens vor dem Formatieren alles getrimmt, dh man könnte einfach ein "mkfs.btrfs /dev/sdx" auf die gesamte SSD (nicht nur eine Partition, möglicherweise ist dazu -f/--force notwendig) loslassen und danach die Dateisystemkennung wieder mit "wipefs -a /dev/sdx" löschen und dann erst die SSD wie gewünscht partitionieren und formatieren.
Durch das Vorgehen „verliert“ man imho höchstens ein paar wenige nicht getrimmte Sektoren, in die das btrfs bereits beim Formatieren Verwaltungsinformationen geschrieben hat.
(Dasselbe ist vermutlich auch mit einigen anderen Dateisystem möglich… aber es läuft fast auf dasselbe hinaus wie die nicht gemountete Partition, wie Holt sie vorgeschlagen hat)


schließlich gibt es aber eigentlich keinen Grund davon auszugehen, dass der nicht partitionierte Bereich am Ende der SSD nicht „frei geblieben“ ist, bis auf vielleicht zB eine Kopie der GPT, denn auf die die unpartitionierten und unformatierten Bereiche eines Speichermediums schreibt ja keine Anwendung und kein Programm.

 

[smutbert]

Was ich fast vergessen hätte


Man kann auch die Host Protocted Area (HPA) vergrößern, also die Reserve, die die SSD vorhält. Dadurch verkleinert man natürlich die nutzbare Kapazität, genau wie mit einer eigens angelegten leeren Partition am Ende der SSD, aber man macht es damit schwieriger bis unmöglich den Bereich irrtümlich zu beschreiben.

Die HPA läßt sich mit

hdparm -Npxxx /dev/sdx

festlegen, wobei p für permanent (also dass der Wert über den nächsten Systemstart hinaus beibehalten wird) und xxx für die Zahl der hinterher noch verfügbaren/zugänglichen Sektoren steht, /dev/sdy ist naturlich wieder durch die passende Gerätedatei zu ersetzen. Der Befehl läßt sich übrigens pro Kaltstart nur einmal ausführen (siehe Manpage von hdparm).

Allerdings vermute ich, dass es gut wäre, den hinteren Bereich oder am besten gleich die komplette SSD zu trimmen bevor man das macht (denn ich bin mir nicht sicher, dass die HPA automatisch als getrimmt/frei markiert wird). Neu partitionieren ist wegen der dann geänderten Kapazität sowieso ratsam...

 

[Holt]

Man kann auch die Host Protocted Area (HPA) vergrößern, also die Reserve, die die SSD vorhält. Dadurch verkleinert man natürlich die nutzbare Kapazität, genau wie mit einer eigens angelegten leeren Partition am Ende der SSD, aber man macht es damit schwieriger bis unmöglich den Bereich irrtümlich zu beschreiben.

Das dürfte aber auf das Gleiche hinauslaufen wie ein unpartitionierter Bereich, denn auch in einer HPA können ja Daten geschrieben werden, der Controller der SSD kann es also nicht als garantiert leere ansehen und damit einfach selbst die Daten löschen, die dort stehen. Man muss also genauso vorher trimmen, was ja genau das Problem im Moment ist.

Man könnte sicher auch einfach auf den unpartitionierten Bereich eine Partition erstellen, diese wird dann von Windows getrimmt und/oder man trimmt diese noch manuell und löscht sie danach wieder.

Das hatte ich ja hier schon vorgeschlagen:

Am einfachste dürfte es sein eine Partition anzulegen und diese mit fstrim zu trimmen und dann nicht in die etc/fstab einzutragen, damit sie nicht gemountet wird.

 

[smutbert]

ja, hast du vorgeschlagen (deshalb habe ich auch geschrieben: "…nicht gemountete Partition, wie Holt sie vorgeschlagen hat" )

mir hat es bis jetzt irgendwie immer besser gefallen, die HPA zu vergrößern statt einer eigenen Partition anzulegen, wenn man Wert auf einen größeren freien Bereich legt und wenn auch nur deswegen, weil man dann beim Partitionieren weniger nachdenken muss, deshalb wollte ich diese Möglichkeit nicht unerwähnt lassen.