Wie voll dürfen SSDs werden?

[Rumo]

LUKS unterstützt TRIM. Einfach bei cryptsetup luksOpen ein --allow-discards mitgeben.

Die SSD haben ja alle eine gewisse Reservekapazität. Wear Leveling funktioniert auch noch wenn alles voll ist. Vielleicht wirds etwas langsamer, wer merkt das schon?

In der Praxis kommt der Fall aber nicht vor, da die Dateisysteme selbst ganz unabhängig vom Speichermedium es nicht mögen 100% voll zu sein. Unter Linux ist meistens eine Root Reserve von 5% eingestellt die verhindert daß du als normaler User die Platte überhaupt voll bekommst.

Je voller das Dateisystem ist, desto aufwendiger ist es für das Dateisystem freien Speicher zu finden, und desto stärker fragmentiert alles. Und Fragmentierung (in extremer Form) macht langsam, auch auf SSD, nicht weil die SSD länger bräuchte um es zu lesen, sondern weil das Dateisystem selber schon länger braucht alle Fragmente einzusammeln.

 

[Holt]

Irgendwo habe ich gelesen, dass SSDs, die mehr als 50% benutzt sind, deutlich langsamer werden und falls die SSD komplett vollgeschrieben wird, sie defekt ist. Was ist darah richtig?

Kaputt gehen darf sie nicht, egal wie voll sie ist und wie wo was geschrieben wird. Langsamer werden SSD i.d.R. schon, wenn sie sehr voll sind, dass ist normal, hängt aber auch von der konkreten SSD und der Nutzung ab, also ob vorher gelöscht und getrimmt wird oder ob man einfach überschreibt.

Wird nicht getrimmt geht den SSDs meist schnell die Frea Area aus und damit wird der Controller gezwingen während des Schreibvorgangs für Freie Pages zu sorgen, also noch gültige Daten kopieren und Blöcke löschen. Dann ist die Schreibrate halt geringere bis deutlich geringer.

Wurde gelöscht, getrimmt und dem Controller etwas Zeit zum Aufräumen gelassen, sollte er genug freie Pages für den nachfolgenden Schreibvorgang haben und idealerweise gibt es keine Performancenachteile.

Bei Festplatten hat man zwar kein physikalisches Problem der Schreibzyklen dafür jedoch ein logisches beim Dateisystem, was dazu führt, dass die zu schreibenden Daten in die wenigen über die Festplatte verstreut liegenden Sektoren geschrieben werden müssen, was eine hohe Fragmentierung zur Folge hat

Das hat nicht Fragmentierung zur Folge, das ist Fragmentierung! Die gibt es genauso auch bei SSDs, denn beide Datenträger stellen nur einen Bereich aufeinanderfolgender LBAs mit normalweise je 512 Byte pro LBA bereit. Die Verwaltung der Dateien und Ordner obliegt dem Filesystem und das funktioniert für beide Datenträger genau gleich.

Der Unterschied ist, dass die Auswirkungen auf die Performance weit geringer sind, aber es gibt sie. Denn statt weniger (vielleicht nur einem) lange Zugriffe muss für jedes Segment je ein Zugriff erfoolgen und wenn das Segment klein ist, dann wird es kurzer Zugriffe und bei kurzen Zugriffen erreichen SSDs eben bei weitem nicht die Transferraten wie bei langen Zugriffen. Im extremsten Fall wäre eine Daten in lauter Fragmente von je einem Cluster, meist 4k, aufgeteilt und dann erhält man eben Transferraten wie in den Benchmarks bei 4k und nicht wie bei sequentiell! Bevor es so weit kommt, muss aber die Fragmentierung schon wirklich extremst sein!

Fragmentierung gibt es also auch bei SSDs, sie hat auch einen gewissen Effekt auf die Performance, aber der ist bei weitem nicht mit dem zu vergleichen, was bei HDDs passiert.

Ich habe auf meiner 3TB HD die 2.7 TiB-Partition mit XFS als Dateisystem schon mehrmal voll bekommen, keine Performance-Probleme beim Lesen. Normalerweise sind an die 20-30GB frei.

Lesen ist kein Problem und die Fragmentierung wirkt sich sowieso bei HDDs wie bei SSDs immer nur auf die betroffenen Dateien aus. Das sind meist die zuletzt geschrieben bzw. stark gewachsenen (wie bei logs) Files, die anfangs auf das leere Dateisystem geschriebene Dateien sind ja nicht fragmentiert, die liest man immer gleich schnell, egal in wie vielen Fragmentie andere Dateien aufgeteilt wurden.

Je mehr man freilässt umso geringer ist das Risiko von Performanceverlust, auch weil der Controller ja bei der Auswahl der NAND Dies beschränkt wird und so nicht mehr die für optimale Performance nötige optimale Verteilung garantieren kann. Wenn man so 10 bis 20% frei lässt, sollte es aber normal keine spürbaren Performancenachteile bringen und wenn, dann allenfalls beim Schreiben. Lesen kann man die NANDs deutlich schneller als Schreiben und daher ist eine suboptimale Verteilung über die NANDs dort so schnell nicht zu bemerken.

Bei HDDs spielt es für die Geschwindigkeit übrigens praktisch egal ob man liest oder schreibt, von paar MB Cache mal abgesehen, aber die bringen fast nur bei kurzen Schreibzugriffen etwas. Bei SSDs ist das halt anders.

 

[highks]

LUKS unterstützt TRIM. Einfach bei cryptsetup luksOpen ein --allow-discards mitgeben.

Bei LUKS mit lvm scheint es nicht so einfach zu sein. Ich habe auch schon mal 1:1 eine Anleitung durchgegangen aber es hat nicht funktioniert.

Ganz unten in den Kommentaren sieht man noch meinen Eintrag, der beschreibt, was bei mir passiert:

Can anybody give me a hint on how to update the initramfs in Mint 15?
I tried the update-initramfs -u command (-u for update existing initramfs) but all I get is this error message:

“update-initramfs: Generating /boot/initrd.img-3.8.0-19-generic
grep: /boot/config-3.8.0-19-generic: No such file or directory
Warning: No support for locale: de_DE.utf8″

And then of course, fstrim doesn’t work, although I changed the lvm.conf and crypttab entries.

Ich hab es dann allerdings nicht weiter verfolgt (Schande über mich, der Autor wollte mir ja noch helfen, aber mir war's dann zu kompliziert - eben weil die Performance sich eigentlich nicht schlecht anfühlt!
Vielleicht fühle ich mich ja irgendwann wieder dazu berufen, es nochmal zu probieren...)

 

[Rumo]

Bei LUKS mit lvm scheint es nicht so einfach zu sein.

Bei mir geht TRIM durch md, luks, lvm problemlos durch. Dateisystem XFS oder ext4.

Meistens liegt es bei luks am fehlenden --allow-discards. Prüfen mit dmsetup:

# dmsetup table
luks: 0 125034496 crypt aes-xts-plain64 [...] 0 9:0 4096 1 allow_discards

Wenn in der crypt Zeile das allow_discards am Ende nicht dabei steht, liegts daran...

Ansonsten muss nur der Kernel aktuell genug sein.

Wie man bei Mint das --allow-discards einstellt weiß ich allerdings auch nicht.

 

[m.Kobold]

Sollte man den Bereich also die 10% unpatitioniert lassen oder kann man auch drauf scheissen?
Weil das programm von meiner samsung ssd mit overprosing ankommt und die patitioniert die festplatte (SSD) nicht komplett... wieso macht das prog das und hat das überhaupt einen sinn?

 

[Holt]

Overprovisioning hat schon einen Sinn, denn damit hat der Controller der SSDs garantiert mehr Free Area und kann daher mehr Daten schnell schreiben, bevor er anfangen muss während des Schreibvorgangs auch erst noch Daten zu Kopieren und Blöcke zu Löschen. Das hält also die Performance bei stärkerer Belastung hoch und vermindert die Write Amplification. Ob es einem den Verlust an Kapazität wert ist, muss jeder selbst entscheiden, aber in Umgebungen in denen TRIM nicht funktioniert, würde ich dringend dazu raten, denn andernfalls kann die Performance mit der Zeit schon spürbar abfallen, weil irgendwann alle adressierbaren LBAs beschrieben worden sind und damit für den Controller so lange gültigen Daten enthalten, bis sie überschrieben werden. Die SSD ist dann also aus seiner Sicht ständig randvoll.

In Bereich die keiner Partition angehören kann normal auch nicht geschrieben werden und damit steht dem Controller diese Kapazität als frei zu Verfügung, wenn die LBAs eben nie beschrieben oder wenigsten hinterher wieder getrimmt wurden. Die unpartitionierten Bereich sollte man also gleich vor der ersten Nutzung oder nach einem Secure Erease anlegen, damit die LBAs darin nicht doch schon für den Controller gültige Daten enthalten, denn in dem Fall ist das witzlos.