ubuntuusers.de

stfischr schrieb:

Ich lösche mal die Abschnitte zum Testen ... hab ich irgendwie verpasst.

Danke - diese sind durch den separaten Artikel SSD/TRIM/Testen ja nun redundant gewesen.

Was haben eigentlich die Abschnitte "relatime" und "Journaling" im Trim-Artikel verloren?

Keine Ahnung - not my business...

aasche schrieb:

Was haben eigentlich die Abschnitte "relatime" und "Journaling" im Trim-Artikel verloren?

Keine Ahnung - not my business...

☺

Was meinen die Anderen dazu? Vielleicht kann man die mit dem Sheduler zusammen in einen Artikel packen und ihn "micro tuning" nennen? Obwohl Sheduler auch schon recht lang ist ...

Huhu!

Man könnte das Journaling in einen anderen Artikel packen, allerdings bezieht sich der Artikelabschnitt "TRIM per Online Discard" indirekt auf das Journaling (wegen Editierens der /etc/fstab).

Das Journaling ist drin, weil in diesem Artikel erklärt wird, welches Dateisystem für die SSD sinnvoll ist. Und zu ext(4) wiederum gehört das Journaling.

Wegen "Online Discard" (→ /etc/fstab) wird kurz (deswegen "Exkurs") auf die Mount-Optionen relatime, noatime und das Abschalten des Journalings (ext) eingegangen.

Liebe Grüße,

Flo

Ich studiere gerade (mal wieder) das Thema "TRIM" für meine SSD (Intel 520, Sandforce-C.). Da ich mehrere Partitionen mit unterschiedlichen Systemen (aber alles ext4) habe, entschied ich mich für "batched discard".

Dabei ist eine Frage offen: wie wird/werden da freie Bereiche an die SSD übermittelt?

• jeder Block einzeln

• oder freie Bereiche von Blöcken

Es werden beide Varianten beschrieben, wobei es heißt: laut ATA-Spezifikation sollen Bereiche übermittelt werden. Andererseits heißt es wieder hier, daß u.a. wegen M$ nur einzelne Blöcke a 1 Sektor übermittelt werden.

Das ganze ist für mich interessant, denn ich möchte die Option -m (minimum size) von fstrim nutzen. Mit -m 1M z.B. werden nur freie Bereich im Dateisystem gesucht, die >= 1 MiB sind. Das geht dann natürlich viel schneller. Wenn die SSD aber damit nix anfangen kann, da sie nur einzelne Blöcke versteht, ist das natürlich sinnlos.

Meine SSD meldet:

# hdparm -I /dev/sda | grep -i trim
	   *	Data Set Management TRIM supported (limit 1 block)
	   *	Deterministic read data after TRIM

Die Blockgröße meiner SSD ist 1 Sektor = 512 Bytes. Es sind hier offensichtlich weder Dateisystemblöcke a 4KiB, noch "erase Blocks" von bis zu 1 MiB gemeint.

Viele Grüße,
Ingo

So, ich trage hier mal meine weiteren Beobachtungen zusammen:

hatte bisher mit der Intel 520 SSD in meinem Ivy-Bridge H87 PC so alle paar Wochen komplette Freeezes und nur der reset-Knopf half. In den Logs nichts zu finden, höchstens mal eine Logdatei mit 0 Byte Größe vom fraglichen Zeitpunkt.

Vor ein paar Tagen konnte ich den Freeze produzieren, indem ich auf allen (insgesamt 4) Partitionen mit ext4 ein 'fstrim' gemacht habe. Kurz danach fror das System ein. Der Verdacht liegt nahe, das die SSD dafür (mit)verantwortlich ist.

Habe jetzt radikal downgegradet und meine "alte" Intel 320 SSD eingebaut und die komplette 520 mit Clonzilla 2.2.0-31 darauf geklont. (Hat nur 5 Minuten gedauert und alle Systeme booten und laufen wie gehabt). Die 320 SSD hat zwar schon 2 Jahre in meinem Vorgängerr-PC auf dem Buckel, aber dort nie Probleme gemacht. Auch jetzt hat sie einen kompletten TRIM rasend schnell (im Vergleich zur 520) und ohne Probleme danach absolviert. Ich werde weiter berichten.

Interessant ist folgender Unterschied der beiden SSD's:

320 hat einen Intel-Controller und sagt:

Data Set Management TRIM supported (limit 8 blocks)
Deterministic read ZEROs after TRIM

520 hat einen Sandforce-Controller und sagt:

ata Set Management TRIM supported (limit 1 block)
Deterministic read data after TRIM

Ich interpretiere das so: "limit 8 blocks" = 8 Sektoren = 4KiB - das ist die Page-größe von ext4 und ist damit optimal.

"limit 1 block" ist die Umsetzung einer Microsoft-Forderung und heißt, jeder Sektor wird einzel getrimmt.

Mein Verdacht für die sporadischen Freezes deutet auch auf den TRIM-Vorgang bzw. die interne garbage-collection hin. Mal sehen, ob das jetzt endgültig gelöst ist.

P.S.: wer Interesse hat, bitte nur mal nach "ThinkPad 520 SSD" im Internet suchen - abenteuerlich 😉 und auch auf kernel.org gibt's dazu was.

fstrim hat auch einen eigenen minimum-parameter, hab ich zwar nie ausprobiert, aber wenn die SSD sich beim trimmen einzelner Sektoren weghängt (wie lange gewartet?) ist das evtl. ein Würgaround

frostschutz schrieb:

fstrim hat auch einen eigenen minimum-parameter ...

Ja, das hatte ich ja anfangs auch gedacht - s. mein erstes Posting dazu. Aber das "Einfrieren" passiert nicht während das TRIM selbst, sondern ein paar Minuten oder noch später danach. Ich liste hier mal auf, wie sich mir die ganze Sache bei der 520 darstellt:

• Die Userland-Tools (fstrim, ext4, ..) für den TRIM nutzen/kennen als kleinste Einheit eine Blockgröße von 4KiB. Die Option "-m" von fstrim bezieht sich nur auf die Größe von zusammenhängenden freien Blöcken im Dateisystem.

• Wie der Kernel das jetzt in ATA(8)-Befehle umsetzt und an die SSD übermittelt, ist mir unbekannt.

• Die SSD speichert die vom Kernel gemeldeten "freien Blöcke/Sektoren/???" erst mal intern - getrimmt ist bis dahin noch garnix.

• Jetzt ist es Aufgabe der Müllabfuhr (hiewr ist das deutsche Wort kürzer als das englische), also des Controllers und der Firmware, in Zeiten geringer Last diese Angaben zu verrechnen und daraus "freie erase blocks" zusammenzustellen. Erst danach kann dann wirklich ein erase block gelöscht werden. Erase blocks sind z.B. 128KiB groß.

• Da hat der Sandforce-Controller in der 520 natürlich eine gewaltige Aufgabe, den es gilt erst mal die gespeicherten Daten eines Erase-Blocks Daten zu entschlüsseln/dekomprimieren und die "leeren Stellen" darin zu finden. Das muß dann offensichtlich mit mehreren Erase-Blocks passieren, dann werden die Teile mit Nutzdaten und die "leeren Teile" zusammengefaßt bis wieder (nach komprimieren) neue komplette Blöcke - die einen mit Nutzdaten, die anderen mit leeren Zellen - entstehen. Erst dann kann in den Flash geschrieben werden.

Und das ist meiner Meinung nach das Problem: der Controller hat jede Menge Arbeit, den TRIM zu verarbeiten. Dabei können sowohl auch mal Fehler auftreten, aber auch "Gedenkpausen" in denen die SSD nach außen so beschäftigt ist, das das Betribssystem meint, die SSD wäre defekt → Freeze. Untermauert wird der Verdacht dadurch, daß solche Freezes nur ganz sporadisch und meistens bei typischen größeren Workloads auftreten. Auch Power-Cycles scheinen einen Einfluß auf das Verhalten zu haben.

Ich habe das hierin der Diskussion gepostet, weilich selbst noch nicht endgültig alles erklären kann. Direkte Hilfe ist wohl auch unwahtrscheinlich bis unmöglich. Deshalb dieser Weg und vielleicht finden sich ja weitere User oderFachleute, die hier was beitragen können, um die Problematik "TRIM" besser zu verstehen und das letztlich auch im Wiki festzuhalten.

Ich selbst bin so ziemlich am Ende mit meinen Recherchen. Um aber den Ärger letztlich wirklich der 520 SSD zuzuschreiben, braucht es noch einen Monat fehlerfreien Betrib mit der 320 SSD, die ja ganz geradeaus "Klartext schreibt" im Gegensatz zur "Blackbox" Sandforce-Controller.

EDIT: die eigentlich viel langsamere 320 SSD (220MB/s) hat übrigens NULL Einfluß auf die gefühlte Geschwindigkeit des Systems, noch auf die Bootzeit von Jessie mit Systemd - das sind konstant 9 Sekunden.

So, mal kurz ein Zwischenbericht:

Bisher läuft mein PC ohne die geringsten Probleme und ohne "Schluckauf" mit der Intel 320 SSD.

Und der Weihnachtsmann war sehr spendabel und hat mir eine Intel S3500 SSD mit 120GB und Intel-Controller gebracht. Die ist inzwischen statt der 320 in Betrieb. Die ist zwar für Server und 24/7 deklariert, aber gleichzeitig auch für 25 power cycles pro Tag spezifiziert - also mehr als ausreichend für Desktop-Betrieb. Und das Schönste ist diese Zertifizierung:

Compatibility:
...
Red Hat Enterprise Linux* 5.5, 5.6, 6.1, 6.3
SUSE* Linux Enterprise Server 10, 11 SP1
CentOS 64bit 5.7, 6.3

Ich sehe die ganze Story jetzt unter diesem Aspekt und werde nicht weiter versuchen, durch BIOS- oder System-Konfiguration die 520 zu zähmen - dafür bekomme ich sicher noch ein paar Euronen, hat ja nur 1 TBW und noch fast 4 Jahre Garantie. Oder sie kommt in ein externes USB3.0-Gehäuse, Datenverlust hatte ich übrigens nie. Die 320 kommt in den Laptop, da ist die S3500 eher ungeeignet, braucht ca. 1 Watt mehr als die 320.

Jetzt warten wir mal noch ein paar Wochen, ob alles weiterhin so perfekt bleibt (was ich stark annehme).

Einen guten Rutsch ins neue Jahr,
Ingo

Huhu!

Ich schließe das Jahr mal mit einer erfreulichen Meldung für SSD- und dann 14.04-Nutzer ab:

SSDs are now being trimmed automatically out of the box. Embarrassingly late, but at least in time for 14.04 LTS.

Und Martin Pitt, der Initiator des Blueprints Enable automatic trimming of SSD drives 🇬🇧 verweist sogar auf unsere Wikiseite:

wiki.ubuntuusers.de/SSD/TRIM explains the details…

Quelle: Ubuntu 14.04 to Feature SSD TRIM Support By Default

Liebe Grüße und ebenfalls allen einen guten Rutsch,

Flo

UbuntuFlo schrieb:

SSDs are now being trimmed automatically out of the box.

Ich gehe mal davon aus, das die Mount-Option discard dazu verwendet wird.

Meiner Meinung nach ist die jedoch nicht immer die beste Wahl, auch batched discard mit einem cron job macht Sinn. Hier ein Beispiel, das mir auf die Schnelle einfällt:

make clean

nach Kernel-Kompilation - da dürfte die SSD beim discard schon schön ins Schwitzen kommen 😉

Aber jetzt nochmal die Frage zur Option -m von fstrim (die klammert der Wiki-Artikel noch komplett aus):

Meine Überlegung ist, daß wenn der durch die Option angegebene "minimum free extent" gleich (oder sogar größer) als die "erase block size" der SSD ist, hat es der Controller in der SSD am einfachsten, da er solche freien Bereiche ohne Umsortieren komplett löschen kann?

Ich habe jetzt bei meiner S3500 mal deshalb einen wöchentlichen Cron-Job mit

fstrim -vm 128KiB /

konfiguriert.
Leider finde ich die Größe der erase blocks für meine SSD in keinem Datenblatt - gibt es da eventuell anderweitige Quellen oder Erfahrungswerte?

Viele Grüße,
Ingo

ingo2 schrieb:

UbuntuFlo schrieb:

SSDs are now being trimmed automatically out of the box.

Ich gehe mal davon aus, das die Mount-Option discard dazu verwendet wird.

Im verlinkten Dingens war erstmal von fstrim die Rede. Hab aber nicht alles durchgelesen.

da dürfte die SSD beim discard schon schön ins Schwitzen kommen 😉

Auf den meisten SSD merkt man so oder so kein Unterschied; es gibt aber halt auch welche die sich für TRIM besonders viel Zeit genehmigen und da ist discard dann richtig spürbar.

Leider finde ich die Größe der erase blocks für meine SSD in keinem Datenblatt

Selbst wenn, wärs wahrscheinlich eh falsch. Das Alignment ist ja nicht gegeben. Wenn dir fstrim ohne -m zu lange dauert, nimm den kleinsten Wert der für dich akzeptabel ist.

frostschutz schrieb:

Selbst wenn, wärs wahrscheinlich eh falsch. Das Alignment ist ja nicht gegeben. Wenn dir fstrim ohne -m zu lange dauert, nimm den kleinsten Wert der für dich akzeptabel ist.

Jo, das hatte ich nicht berücksichtigt. Fazit daraus: man müßte für -m ein Vielfaches der Größe von "erase blocks" angeben. Bei z.B. 1MiB wären dann mindestens 7 komplette "erase blocks" dabei.

Um hier das Optimum zu finden, müßte man irgendwie die Gesamtgröße "freier extents" als Funktion ihrer Größe ermitteln. Der Kernel tut das ja bei jedem mount-Vorgang und legt dazu eine Tabelle für das ext4-Dateisystem an. So versucht er, jedem Schreibvorgang zusammenhängende Blöcke (als extents) bereitzustellen und auch Schreibvorgänge zusammenzufassen.

Es arbeiten hier also 2 unabhängige Funktionen an der selben Aufgabe:

• der Kernel (bzw. ext4) versucht, durch die Nutzungs von extents Fragmentierung zu vermeiden und möglichst zusammenhängende Bereiche in einem Rutsch zu beschreiben.

• die garbage collection der SSD (bzw. deren Controller) versucht, Schreibzugriffe so umzusortieren, daß komplette "erase blocks" dabei herauskommen.

Das sollte doch eigentlich aufeinander abgestimmt sein, um beide Mechanismen optimal zu nutzen?
(Ich verglcheiche das jetzt mal mit einer Regelung auf einen Zielwert: da können 2 unabhängige Regler mit unterschiedlichen Zeitkonstanten in Extremfall sogar zu Regelschwingungen führen).

Kennt Jemand so ein Tool, welches die Kerneltabelle mit den freien extents auslesen und "human readable" nach Größe und Häufigkeit ausgeben kann?

Viele Grüße,
Ingo

ingo2 schrieb:

Kennt Jemand so ein Tool, welches die Kerneltabelle mit den freien extents auslesen und "human readable" nach Größe und Häufigkeit ausgeben kann?

Habe die Antwort selbst gefunden - die e2fsprogs sind dein Freund:

DESCRIPTION
       e2freefrag  is used to report free space fragmentation on ext2/3/4 file
       systems.  filesys is  the  filesystem  device  name  (e.g.   /dev/hdc1,
       /dev/md0).   The e2freefrag program will scan the block bitmap informa‐
       tion to check how many  free  blocks  are  present  as  contiguous  and
       aligned  free  space.  The percentage of contiguous free blocks of size
       and of alignment chunk_kb is reported.   It  also  displays  the  mini‐
       mum/maximum/average  free  chunk  size  in the filesystem, along with a
       histogram of all free chunks.  This information can be  used  to  gauge
       the level of free space fragmentation in the filesystem.

Hier meine Systempartition:

# e2freefrag /dev/sda2
Device: /dev/sda2
Blocksize: 4096 bytes
Total blocks: 7864320
Free blocks: 6102924 (77.6%)

Min. free extent: 4 KB 
Max. free extent: 1833004 KB
Avg. free extent: 1484 KB
Num. free extent: 16441

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          3573          3573    0.06%
    8K...   16K-  :          2080          4910    0.08%
   16K...   32K-  :          1335          6993    0.11%
   32K...   64K-  :          2681         31442    0.52%
   64K...  128K-  :          2031         47594    0.78%
  128K...  256K-  :           846         38633    0.63%
  256K...  512K-  :           826         76268    1.25%
  512K... 1024K-  :           755        138898    2.28%
    1M...    2M-  :          1269        485167    7.95%
    2M...    4M-  :           673        450989    7.39%
    4M...    8M-  :           156        216879    3.55%
    8M...   16M-  :            92        259474    4.25%
   16M...   32M-  :            43        230501    3.78%
   32M...   64M-  :            42        478046    7.83%
   64M...  128M-  :            21        440074    7.21%
  128M...  256M-  :             8        418232    6.85%
  256M...  512M-  :             2        193031    3.16%
  512M... 1024M-  :             3        485524    7.96%
    1G...    2G-  :             5       2094823   34.32%

Danach reicht es also völlig aus, nur Bereiche mit minimum-free-extent von 1MiB zu trimmen, alles darunter sind mit < 6% "Erdnüsse" und kosten nur unnötige Aktionen.

Ebenfalls interessant ist die Aussage:

... contiguous and aligned free space.

Fragt sich nur, ob sich das auf ext4-Blöcke oder auf die SSD bezieht?

Habe jetzt meinen wöchentlichen Trim auf -m 1MiB geändert.

Der Vollständigkeit halber hier noch die TRIM-Zeiten für verschiedene 'minimum-free-extent' Werte mit der Zahl "getrimmter Bytes":

		  4 KiB		9 sec.	24986820608 bytes
		128 KiB		4 sec.	24691003392 bytes
		  1 MiB		3 sec.	23647264768 bytes

Anmerkung: Die 520 SSD hat für einen Lauf mit 4KiB blocks ein paar Minuten benötigt!

So nuetzlich praktische Erfahrungswerte auch sind: koennte dieser sehr spezielle Monolog evtl. in einer eigenen Diskussion fortgesetzt werden? Danke.