Re: SSD : prüfen ob trim-Unterstützung funktioniert und Parameter für fstab

[Martin Steigerwald <Martin@lichtvoll.de>]

Am Freitag, 30. November 2012 schrieb Jochen Spieker:
> Martin Steigerwald:
> > Nuja, machen sie ja auch – teilweise. Dennoch profitiert die SSD
> > aufgrund der grundsätzlichen Natur der Flash-Chips von begleitenden
> > Maßnahmen. Es gibt ne maximale Anzahl von Schreibvorgängen,
> > SSD-Firmwares machen Wear Leveling usw. Solange
> > Nachfolge-Technologien noch nicht verfügbar sind, und da sind nach
> > meinen groben Informationen einige am Start,
> 
> -v, please.

Oh, das weiß ich nicht mehr, auf welchen Seiten ich dazu rumgelesen habe.

Ich find es jetzt auch grad nicht mehr. Da gab es einen schönen Artikel zu, 
der andeutete, dass SSDs wahrscheinlich nur eine Übergangslösung sein 
werde und verschiedene andere Technologien schon in den Startlöchern 
stünden.

Angesichts dessen, dass ich das jetzt aber nicht auf Anhieb wieder finde… 
Wenig hilfreicherweise kommen bei Suchen auf Referenzen auf Adobe Flash, 
das mich gerade und auch sonst nullkommagarnix interessiert. Ah, "ohne die 
Wörter" – das ist besser.

Nee, alles was ich momentan finde ich Phase Change Memory usw. klingt nicht 
so konkret wie das, was ich las. Und ich find auch nichts in meinen 
Lesezeichen. Passe also erstmal. Wenn mir das wieder unterkommt, melde ich 
mich nochmal.

> > Und wenn ich wirklich mal unterschiedliche Benutzer mit
> > unterschiedlichen Passwörtern/Schlüsseln verschlüsseln möchte, geht
> > das ohnehin nur mit einem Dateisystem-basierten Ansatz. Ich nutze
> > dafür ecryptfs.
> 
> Mehrere Passwörter oder Schlüssel für das gleiche Dateisystem geht
> wunderbar mit LUKS. Dann sehen aber natürlich alle die gleichen Daten.
> Ich nehme an, das machst Du mit ecryptfs nicht.

Genau das möchte ich aber nicht. Zum Beispiel um Privates von 
Geschäftlichem strikt zu trennen. Mit ecryptfs kann ich das 
Verschlüsselungspasswort für geschäftliche Daten auch mal an einen anderen 
Mitarbeiter weitergeben, ohne dass dieser meine privaten Daten 
entschlüsseln könnte.

Ein weiterer Vorteil ist für mich auch das Backup: Ich spare mir das 
Entschlüsseln und erneute Verschlüsseln oder ein blockbasiertes Backup. 
Stattdessen lasse ich rsync einfach über die verschlüsselten Daten rennen.

Nachteile hat es natürlich auch: Die Verzeichnisstruktur, das Datum von 
Einträgen sowie deren ungefähre Größe ist sichtbar. Und möglicherweise ist 
der Overhead etwas größer. Wobei ich mir da bei ecryptfs nicht mal sicher 
bin. Das ist gefühlt etwa doppelt so schnell wie encfs, das ich zuvor 
einsetze, und müsste meines groben Wissens mittlerweile auch Hardware AES 
einsetzen, sofern im Prozessor verbaut und von Linux unterstützt. Nur die 
8 KiB mehr *pro Datei* stören mich etwas. Wollte ecryptfs stattdessen mit 
erweiterten Attributen verwenden, das wäre wahrscheinlich platzsparender 
gewesen. Nur da gab es Probleme, die ich damals auch an die ecryptfs-
Mailingliste berichtete und zurück bekam, dass dieser Modus kaum getestet 
werde. Da hab ich dann erstmal die +8 KiB-Variante pro Datei verwendet und 
dabei ist es bislang geblieben.

> >> Ich habs jedenfalls so gemacht: SSD im Laptop habe ich einfach per
> >> Clonezilla von der Scheibe rübergeklont. Das hat ewig gedauert, weil
> >> alles eben komplett verschlüsselt ist.
> > 
> > Also maximal unpraktisch für die Lebensdauer der SSD.
> 
> So what? Ich weiß ja nicht, wie schlimm es inzwischen mit moderneren
> SSDs ist, aber meine X25 ohne TRIM funktioniert seit 3,5 Jahren
> wunderbar, obwohl der größte (und am meisten beschriebene) Teil
> verschlüsselt ist (dm-crypt+LUKS).

Nunja, die Intel gehören meinem Eindruck auch zu den zuverlässigeren SSDs. 
Da gibts bei Anandtech irgendwo ein Schaubild von Intel zur Annual Failure 
Rate. Echte Probleme gab es, glaub das war mit der X25, in 0,4% aller 
Fälle. Das sind immer noch 4 von 1000 SSDs pro Jahr. Werte anderer 
Hersteller sah ich da nicht… las aber hier und da, dass Intel erstmal 
einer der wenigen sei, die diese Werte überhaupt veröffentlichen, und 
zweitens auch eher einer derjenigen ist, die zuverlässige SSDs bauen.

> Ein paar Zahlen:
> 
> $ mount | grep ext4 | awk '{ print $1 }' | while read f;  do echo $f ;
> sudo tune2fs -l $f | grep -E '^(Lifetime|Filesystem created)' ; done
> /dev/disk/by-uuid/f56621f8-a6cf-4f13-abb5-2db563f292da
> Filesystem created:       Wed Apr 20 21:02:25 2011
> Lifetime writes:          14 GB
> /dev/mapper/manowar-home_crypt
> Filesystem created:       Wed Apr 20 21:06:36 2011
> Lifetime writes:          1907 GB
> /dev/mapper/manowar-usr
> Filesystem created:       Wed Apr 20 21:06:51 2011
> Lifetime writes:          74 GB
> /dev/mapper/manowar-var
> Filesystem created:       Wed Apr 20 21:06:54 2011
> Lifetime writes:          480 GB

merkaba:~> tune2fs -l /dev/merkaba/home | egrep "(Lifetime|creat)"
Filesystem created:       Thu May 19 21:05:00 2011
Lifetime writes:          3158 GB
 
> Das sind 2,5TB in 19 Monaten. Laut Datenblatt garantiert Intel 20GB/Tag
> für fünf Jahre. Macht 36TB.

3 TB in 18 Monaten. Ohne /, das auch nochmal einigen Durchlauf hat, aber 
bei BTRFS weiß ich nicht, inwiefern ich da die komplette Menge an 
geschriebenen Daten rausbekomme.

Dito für die Intel SSD 320.

3158 GB in 18 Monaten macht etwa 175 GB im Monat.

20 TB in 5*12 = 60 Monaten sind 333 GB im Monat, wenn auf 10er-Basis 
gerechnet.

Das ist also noch gut drunter, gut die Hälfte, allerdings spricht Intel 
auch nur von "Minimum Useful Life/Endurance Rating" und:

"This SSD will have a minimum of five years of useful life under typical 
client workloads with up to 20 GB of host writes per day."

Und da käme es jetzt stark auf die Definition von "useful" an :). Von einer 
garantierten Performance steht da nichts. Eine SSD könnte auch mit 
festplatten-ähnlichen Geschwindigkeit durchaus als benutzerbar gelten :)

Aber gut, das mal gerechnet zu haben.

Was bei mir noch mit reinspielt, ist wahrscheinlich die Nepomuk-Desktop-
Suche. Die sehe ich immer mal wieder auf der SSD rumrödeln. Da gebe ich 
zu: Diese abzuschalten hat möglicherweise einen größeren Effekt wie manch 
andere Optimierungsmaßnahme. Aber wie groß der Einfluß von Nepomuk ist, 
müsste ich auch erstmal messen.

Wie dem auch sei, anläßlich dieser Daten könnte es auch ohne Trim ganz gut 
gehen.

Allerdings in Bezug auf DM-Crypt sehe ich die Ext4-Werte erstmal nicht als 
autoritativ an. Denn das käme auch mal drauf an in welchen Blockgrößen DM-
Crypt komprimierte Daten schreibt. Ist das wirklich Page-granular, also 4 
KiB-Blöcke? Falls die Blockgröße größer ist, gibt es mehr oder weniger 
großen Verschnitt und die Ext4-Werte sind nur eingeschränkt 
aussagekräftig.

Die Intel Slides mit dem Vergleich in Bezug Lebensdauer und Performance 
bei wieviel Prozent freiem Speicher auf der SSD finde ich grad auch nicht. 
Ah doch, eine zumindest:

Intel Solid-State Drive 320 Series
Random Workload Characterization
Kapitel 3 und 4.

http://cache-www.intel.com/cd/00/00/49/23/492354_492354.pdf

Und das sieht doch durchaus interessant aus. Hier zeigen sich, wenn ich 
das recht verstehe, schon innerhalb 2 Stunden, allerdings ständigen 
Schreibens, Performance-Probleme, falls kein Over Provisioning zum Einsatz 
kommt. Das ist natürlich ein krasser Workload, der der SSD wenig 
Gelegenheit zum Wear Leveling gibt, das die Firmware dann aber 
möglicherweise doch irgendwann durchführen wird, was ein Grund für die 
geringere Performance ohne Overprovisioning sein könnte. Und das wird so 
in typischen Desktop-Workloads nicht vorkommen.

Denn ohne Overprovisioning steht der SSD weniger freier Speicher zum 
Umkopieren zur Verfügung, was die Dinge für die Firmware komplizierter 
machen dürfte.

Ja, viel admistrativer Konjunktiv, doch letztlich ist das, was die SSD-
Firmware so macht, teilweise zumindest Raterei.

Wer noch was Lesen möchte:

http://en.wikipedia.org/wiki/Write_amplification

Das ist durchaus eben auch relevant. Und soweit ich das begriffen habe, 
dann doch recht gut verstanden und bekannt.

Durch weniger freien Speicher auf der SSD steigt die Write Amplification, 
also das, was die SSD-Firmware durch die Umkopiererei mehr schreiben muss. 
Also führen 200 GB Host Writes bei einem Faktor von 1,5 eben zu 300 GB 
Schreibvorgängen auf der SSD.

Allerdings spricht Intel in der "Garantie" da von Host Writes. Streng 
genommen müsste der Wert also auch bei randvoller SSD gelten. Ob das bei 
Intel aber wirklich mal jemand so getestet hat?

> Ja, ich hatte schon einmal das Gefühl, dass das Teil irgendwie
> langsamer geworden ist. Daher habe ich ein Secure Erase gemacht und
> ein Backup zurückgespielt. Heute bin ich aber nicht sicher, ob ich mir
> das nicht eingeredet habe. Hab viel zum Thema gelesen zu der Zeit.

Hmmm. Da wäre gut, nun Messwerte zu haben :).

Ich hab bislang noch keinen Anlaß, einen Secure Erase auf diese Intel SSD 
320 zu machen, nach dem Initialen, um den Standard-Schlüssel durch einen 
neuen zu ersetzen und das Windows 7 auf der SSD effizient zu entsorgen.

Nur das BTRFS mach ich evtl. mal neu. Über 30 Sekunden Schreib-Aktivität 
bei einem fallocate -l 2G deutet auf extrem fragmentierte freie 
Speicherbereiche hin. Da ich da aber auch nicht wirklich was von zu merken 
scheine, eilt das nicht. Allerdings gibt es mittlerweile auch ein paar 
Optionen, die BTRFS etwas effizienter einrichten.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7