SSD + Verschlüsselung + Trim

[PaterPeng]

Hallo Forengemeinde,

ich benutze jetzt seit ca. einem Jahr eine SSD (siehe Signatur). Seit neustem habe ich ein verschlüsseltes /home Verzeichnis.
Die SSD unterstützt TRIM.

Meine Fragen:
1) Funktioniert TRIM überhaupt zuverlässig, wenn das Laufwerk (teil-) verschlüsselt ist?

2) Was passiert genau, wenn ich jetzt im Betrieb das wiper.sh Skript laufen lasse?

3) Ist das wiper wiper.sh nur nötig, wenn ich einen Kernel < 2.6.33 einsetze? Bzw. was ist genau der Unterschied zwischen wiper.sh und TRIM?

4) Lohnt es sich, wegen TRIM in Lucid einen neueren Kernel über die Backports zu installieren? (Und dann wiper.sh nicht mehr ausfürhen zu müssen?)

5) Wie kann ich die Abnutzung unter Linux überwachen? (-> z.B Benchmarks?)

Die gefühlte Performance ist mit Verschlüsselung minimal geringer; das ist kein Problem. Ich habe momentan nur Angst, dass ich die SSD durch mein momentanes Nutzungsverhalten zu schnell abnutze.

Im Internet wird viel geschrieben aber sehr oft habe ich den Eindruck, dass die Leute überhaupt keine Ahnung haben, was eigentlich abgeht. Vielleicht weiß jemand hier ein bisschen genauer bescheid.

Bin gespannt auf eure Antworten

 

[yatpu]

die zugriffszeit alleine machts noch nicht. wichtig ist auch die fähigkeit viele zugriife gleichzeitig verkraften zu können. genau daran sind nämlich die ersten ssd mit mlc-chips gescheitert, da der damalige jmicron-controller (jmf602 iirc) brutal einbrach bei mehreren zugriffen. einfaches sequenzielles schreiben war kein problem, aber mehrere kleine zugriffe in kürzester zeit und der pc kam zum stehen für einige sekunden.

 

[Evilandi666]

Stimmt, das ist auch noch wichtig.

 

[PaterPeng]

was habt ihr denn teilweise gegen das benchmarken?

Ich will jetzt testen, ob meine SSD noch die Leistung bringt, die sie vor einem halben Jahr gebracht hat und dafür ist sowas wie atto eine super Möglichkeit.

Gerade weil ich mit der SSD primär arbeiten und nur sekundär benchmarken will (@linrunner) ist mir ein Gefummel mit dd zu aufwändig.

 

[Evilandi666]

Läuft aber zwangsläufig auf sowas wie dd leider hinaus unter Linux

Ich hab übrigens nichts gegen das Benchmarken - nur ich glaube wenn du es nicht merkst dass sie langsamer wird, wird sie es auch nicht - und wenn ist es egal - wenn du es eh nicht merkst
(Das ist im Prinzip die Diskussion ob Benchmarks überhaupt eine realitätsnahe Situation abbilden zwischen mir und yatpu )

 

[yatpu]

ich hab auch nichts gegen benchmarks. sie sind ein passabler weg um feststellen zu können, ob alles "passt". z.b. bei nem neuen computer oder neu eingebauter hardware. entspricht das ergebnis weitgehend den erwartungen, ist warscheinlich alles io, gibt es deutliche abweichungen, lohnt es sich tiefer zu graben.

btw: es gibt durchaus schon einige benchmarks für linux:
http://www.thomas-krenn.com/de/wiki/I/O_Performance_Benchmarking_Tools_im_Überblick

 

[kalibari]

Irgendwann. Jaja... :thumbdown:

Was daran unsicher sein soll, wenn man einen zuvor verschlüsselt gespeicherten Block freigibt, erklärt er vorsichtshalber nicht. Die Berechnung des Offsets aufgrund der LUKS- und/oder LVM-Header erledigt der wiper.sh-Patch in wenigen Zeilen. Kann kein so großer Aufriß sein, das endlich in den Device Mapper einzubauen.

Also meiner Meinung funktioniert der wiper.sh Patch bei mir nicht (hdparm 9.36). Wie kann man da überhaupt sicher feststellen ob es wirklich funktioniert?

 

[PaterPeng]

Also meiner Meinung funktioniert der wiper.sh Patch bei mir nicht (hdparm 9.36). Wie kann man da überhaupt sicher feststellen ob es wirklich funktioniert?

An der Ausgabe des Skripts! Oder meinst du was anderes?

christoph@thinkpad:~$ sudo wiper.sh --commit --verbose /dev/sda1
[sudo] password for christoph: 

wiper.sh: Linux SATA SSD TRIM utility, version 2.8, by Mark Lord.
rootdev=/dev/sda1
fsmode2: fsmode=read-write
/: fstype=ext4
freesize = 12852576 KB, reserved = 128525 KB
Preparing for online TRIM of free space on /dev/sda1 (ext4 mounted read-write at /).

This operation could silently destroy your data.  Are you sure (y/N)? y
Creating temporary file (12724051 KB).. 
Syncing disks.. 
Beginning TRIM operations..
get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.2356

/dev/sda:
trimming 3768318 sectors from 64 ranges
succeeded
trimming 3850240 sectors from 64 ranges
succeeded
trimming 3768321 sectors from 64 ranges
succeeded
trimming 3883007 sectors from 64 ranges
succeeded
trimming 3194882 sectors from 64 ranges
succeeded
trimming 3522560 sectors from 64 ranges
succeeded
trimming 3309566 sectors from 64 ranges
succeeded
trimming 151210 sectors from 3 ranges
succeeded
Removing temporary file..
Syncing disks.. 
Done.
christoph@thinkpad:~$

 

[kalibari]

Ja die Ausgabe bekomme ich schon. Irgendwie hab ich mir erhofft, dass meine sich die Performance meiner Partition verbessert. Im November sah das bei mir noch so aus:

$ hdparm -tT /dev/mapper/crypt
Timing cached reads: 6704 MB in 2.00 seconds = 3352.72 MB/sec
Timing buffered disk reads: 658 MB in 3.00 seconds = 219.09 MB/sec

Jetzt sieht es bei mir so aus:

$ hdparm -tT /dev/mapper/crypt
Timing cached reads: 5592 MB in 2.00 seconds = 2796.30 MB/sec
Timing buffered disk reads: 394 MB in 3.01 seconds = 130.96 MB/sec

$ df -h
Dateisystem Größe Benut Verf Ben% Eingehängt auf
/dev/mapper/crypt 202G 100G 48G 55% /crypt

 

[yatpu]

trim wirkt sich eher auf die schreibleistung aus. beim lesen ist es nämlich egal, wieviel die ssd noch an freien zellen hat.

 

[kalibari]

Und was ist dann der Grund warum die Leseleistung einbricht? Ich hab mittlerweile die Partition gelöscht und dann mit wiper bearbeitet und das BU aufgespielt. Jetzt bin ich wieder bei 220 MB/sec. Mal sehen wie lange das hält.