Re: SSD : prüfen ob trim-Unterstützung funktioniert und Parameter für fstab
Am Samstag, 1. Dezember 2012 schrieb Jochen Spieker:
> Martin Steigerwald:
> > Am Freitag, 30. November 2012 schrieb Jochen Spieker:
> >> Martin Steigerwald:
[…]
> >> 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.
>
> Hab ich mir doch gedacht. Wobei ich da jetzt nicht den großen
> Unterschied zu mehreren LUKS-Volumes sehe, abgesehen von der größeren
> Flexibilität bei der Zuteilung des Plattenplatzes.
Ja, die ist mir aber auch wichtig.
Nun letztendlich haben beide Ansätze ihre Vor- und Nachteile.
Für mich ists momentan eher eine persönliche Vorliebe. Und eben eine
gewisse Vorsicht in Bezug auf SSDs.
> > 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.
>
> Damit bin ich allerdings auch mal auf die Nase gefallen. Als ich
> Schatzis Ubuntu aus dem Backup restoren wollte und feststellte, dass das
> nicht einfach so[tm] funktioniert. Naja, klarer Fall von selbst Schuld.
>
> > Nachteile hat es natürlich auch: Die Verzeichnisstruktur, das Datum von
> > Einträgen sowie deren ungefähre Größe ist sichtbar.
>
> Genau das behagt mir irgendwie nicht. Da verrät meines Erachtens das
> TRIMmen von LUKS-Volumes weniger interessante Metadaten.
>
> >> 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.
>
> Auch die werden mit den neueren Produktionsprozessen leider schlechter.
Hast Du da Hinweise zu? Hab ich bislang noch nichts gehört.
> > 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.
>
> Ich finde gerade auch den Link nicht mehr, aber Anandtech schrieb
> letztens etwas von ein bis zweistelligen Prozentzahlen an Garantiefällen
> bei einigen Modellen. Da klingen 0,4% schon prima.
Nun, ich las da mal von 2-3%, was ja durchaus höher ist. Wollte ich aber
erst nicht kund tun, weil ich auch die Quelle nix mehr weiß.
> > Allerdings in Bezug auf DM-Crypt sehe ich die Ext4-Werte erstmal nicht als
> > autoritativ an.
>
> Guter Punkt. Und das erinnert mich daran, dass man auch die SSD fragen
> kann. :)
>
> $ sudo smartctl -a /dev/sda | grep ^225
> 225 Host_Writes_32MiB 0x0000 199 199 000 Old_age Offline - 154285
>
> Korrekt mit Basis 2 komme ich dann auf 4,7TiB in 3,5 Jahren. Write
> Amplification sieht man damit natürlich auch nicht.
merkaba:~> smartctl -a /dev/sda | grep Host_Writ
225 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 169866
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 169866
Also 5,18 TiB. Also entweder hat die BTRFS-Partition doch auch noch einen
gehörigen Anteil an den Schreibzugriffen, oder ich hab da auch mehr
Verschnitt drin, als ich erwartet hätte.
Interessanterweise gibt es auch ein paar Erase Fail Counts:
SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
3 Spin_Up_Time 0x0020 100 100 000 Old_age Offline - 0
4 Start_Stop_Count 0x0030 100 100 000 Old_age Offline - 0
5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 4009
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1563
170 Reserve_Block_Count 0x0033 100 100 010 Pre-fail Always - 0
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 169
183 Runtime_Bad_Block 0x0030 100 100 000 Old_age Offline - 0
184 End-to-End_Error 0x0032 100 100 090 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
192 Unsafe_Shutdown_Count 0x0032 100 100 000 Old_age Always - 143
199 UDMA_CRC_Error_Count 0x0030 100 100 000 Old_age Offline - 0
225 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 169867
226 Workld_Media_Wear_Indic 0x0032 100 100 000 Old_age Always - 2203702
227 Workld_Host_Reads_Perc 0x0032 100 100 000 Old_age Always - 49
228 Workload_Minutes 0x0032 100 100 000 Old_age Always - 12835770
232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0
233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always - 0
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 169867
242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 282852
Die sind aber seit smartctl-a-2011-12-16-nach-langem-selbsttest.txt nicht
mehr geworden. Und daher denke ich unkritisch. Gab wohl einfach ein paar
Flash-Zellen, die nicht so fit waren. Ganz am Anfang am 23.6.2011 stand da
einem langem Selbstwert noch eine Null drin.
Interessant auch die Host-Reads. Immerhin 8,63 TiB. Hätte ich an sich aber
mehr erwartet. Doch schon recht schreibintensiv meine SSD-Nutzung :)
Sieht alles gut aus. Daher mache ich mir in Bezug auf die SSD auch keine
Gedanken. Der scheints mal gut zu gehen…
Interessant wäre, was Media_Wearout_Indicator genau aussagt. Allerdings
nehme ich 0 als Roh-Wert da auch mal als guten Wert :)
> > http://cache-www.intel.com/cd/00/00/49/23/492354_492354.pdf
>
> Interessant, danke! Dass das so krass ist, überrascht mich doch.
> Wahrscheinlich wirklich gut, dass ich von meinen 80GB knapp 8GB
> freigelassen habe.
Ich denke, das sind dann teilweise aber auch vorrübergehende Einbußen.
Sobald man der SSD-Firmware wieder etwas Zeit gibt, sich nach so einem
Schreibsturm zu organisieren, dürfte die Performance auch wieder besser
werden.
Von den 300 GB habe ich eine 20 GiB Partition frei. Dateisystem-technisch
sind etwa 13,6 GiB frei. Ich fahre Trim allerdings auch nicht per Mount-
Option, sondern schieb einfach manuell immer mal wieder ein fstrim drüber.
Vor allem, wenn ich die SSD schreibend stark beansprucht habe.
Könnte ich auch einen Cron-Job mit machen, war ich aber bislang zu faul
zu.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: