SSD + Verschlüsselung + Trim

PaterPeng

New member
Registriert
6 Jan. 2010
Beiträge
568
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 :)
 
1) Ja, sofern es eCryptfs ist (Ubuntu Homeverzeichnisverschlüsselungsdingens) dann sollte auto trim gehen, sofern das darunterliegende Lauwerk mit discard gemountet wurde. (geht es nicht, merkst du es schnell meist - dann bootet Ubuntu nämlich nicht mehr. Hab das aber auch schon benutzt -> geht.)

2) Wiper.sh markier manuell die gelöschten Blöcke und gibt das der Festplatte weiter - grob gesagt.

3) ja, ausser autotrim klappt nicht - aus welchen Gründen auch immer. Unterschied siehe 2)

4) Ja, finde ich, da wiper.sh doch recht lange braucht. (oder ist das nicht normal bei mir?)

5) Gar nicht so wirklich, eventuell ein tmpfs Laufwerk im Ram mit urandom Daten füllen und die danach auf die SSD schreiben - das ist einigermaßen realistisch. (Stand hier neulich irgendwo in einem Thread - kp wo.)
 
Wie sieht man denn, wenn man nen Kernel >= 2.6.33 einsetzt, ob TRIM wirklich korrekt funktioniert?
 
Sofern Ubuntu problemlos läuft, wenn die Dateisysteme in /etc/fstab mit discard gemountet sind, gar nicht.
 
danke, thorminator

ich hab jetzt den 35er Kernel installiert und discard gesetzt.
Der Test mit den Nullen hat funktioniert :thumbsup:
 
gib mal fdisk -lcu ein . wenn der startsektor aller partitionen durch 2048teilbar ist, ist alles auf 1 mb ausgerichtet. zumindest sollten alle partitionen an durch 8 teilbaren sektornummern beginnen
 
Code:
christoph@X200s:~$ sudo fdisk -lcu
[sudo] password for christoph: 

Platte /dev/sda: 64.0 GByte, 64023257088 Byte
255 Köpfe, 63 Sektoren/Spur, 7783 Zylinder, zusammen 125045424 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00062b82

   Gerät  boot. 	Anfang    	Ende 	Blöcke   Id  System
/dev/sda1   *    	2048   119851007	59924480   83  Linux
/dev/sda2   	119853054   125044735 	2595841	5  Erweiterte
/dev/sda5   	119853056   125044735 	2595840   82  Linux Swap / Solaris

Passt das so?
 
Nope, daher immer mit fdisk -uc partitionieren und dann im Installer nur noch formatieren ;)

Partition 2 passt nicht: 119853054 % 2048 != 0 (Auch wenn es eine erweiterte ist, müsste die ausgerichtet sein.)

Um Platz zu sparen, würde ich 2 primäre machen, weil du sonst bei sda5 unnötig Abstand verschenkst.

(%=Modulo, Teilung müsste Restfrei sein, dann würde es passen.)
 
ich verstehe zwar nciht, warum für eine einzige partition erst noch ne erweiterte partition angelegt wird, anstatt gleich ne primäre partition anzulegen für swap, aber egal.
obs passt?
rechnen wir doch mal:
2048 / 2048 = 1 <== passt
119853054 / 2048 = 58521,9990234<== passt nicht, ist aber egal
119853056 / 2048 = 58522 <== passt
ergo: alles in ordnung

edit:
bei der erweiterten partition ists wurscht! die ist nur ne verwaltungsstruktur für logische partitionen. in der erweiterten partition selber wird nichts geschrieben, daher ist deren alignment wumpe. bei der swap-partition dagegen stimmt das alignment. nur das zählt.
 
Nö, ischs nicht. Hab ich zumindest mal gelesen!

Aber hey - wenn es nur um Swap geht, isch es doch super schnell korrigiert oder?

fdisk -uc /dev/sdx alles ausser part 1 löschen, neue anlegen, zweimal enter (Vorgeschlagenen Start und Endsektor nehmen), neue UUID in /etc/fstab eintragen an die Stelle der halten, Schwupps 100% korrekt aligned. :)

Achso, natürlich die neue Partition mit gparted oder so kurz als swap "formatieren" (eher markieren).
 
Ich hab mir gestern noch 4GB RAM bestellt. Dann hab ich 6GB, entferne die erweiterte und die swap-Partition und gut ist :D
 
Evilandi666' schrieb:
Partition 2 passt nicht: 119853054 % 2048 != 0 (Auch wenn es eine erweiterte ist, müsste die ausgerichtet sein.)
Quatsch. sda2 als erweiterte Partition muß nicht ausgerichtet werden, da liegt doch gar kein Filesystem drauf. Enthaltenen logische Partitionen sind ja ausgerichtet, wie der Swap auf sda5. sda1, das Root-Filesystem (Mountpoint /), ist auch korrekt ausgerichtet.

Allerdings würde ich dringend empfehlen, eine separate Partition für die Benutzerdaten anzulegen (Mountpoint /home). Für das Root-FS reichen 10-12GB.
 
Also ich hab schon öfters gelesen, dass selbst die Erweiterten korrekt aligned sein müssen.

Und wie oben editiert, bei Swap ist das ja in 0,nichts korrigiert.
 
Evilandi666' schrieb:
Also ich hab schon öfters gelesen, dass selbst die Erweiterten korrekt aligned sein müssen.
Wozu? Das ist nur ein Platzhalter. Im Betrieb zugegriffen wird nur auf primäre und logische Partitionen.
 
wichtig ist nur, dass dateisysteme (inkl. swap) richtiges alignment haben. die erweiterte partition selber ist nur eine verwaltungsstruktur, die einmal angelegt und danach nie wieder beschrieben wird (außer beim partitionieren). die sektoren, die in obigem fall zwischen dem beginn der erweiterten partition und der logischen partition liegen sind größtenteils frei (im ersten liegt der extended boot record für die folgende logische partition) und bliben es auch. sie stellen lediglich verschenkten platz dar. probleme bereiten sie aber nicht.
 
Jungs ich habs mir nicht ausgedacht, gebe nur das weiter was ich gelesen habe. ;)
Ich weiß durchaus was erweiterte Partitionen sind, ihr braucht das also nicht 5 x erklären.
 
dann hast du meiner meinung nach was gelesen, was jemand geschrieben hat, der die materie nicht verstanden hat. ich sehe nichts, was aus technischen gründen gegen eine nicht korrekt alignte erweiterte partition spricht.
 
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben