SSD und TC-AES: Perfomance ? Lifetime ?

Die Frage ist doch immer, gegen was für eine Art unerwünschten Zugriffs muß/will man sich schützen. Geht es nur darum, dass die Kinder / Ehefrau die den Rechner ebenfalls benutzen nicht an bestimmte Daten kommen oder dass ein "verlorenes" Notebook dem "Finder" nicht auch gleich noch eine Menge über den rechtmäßigen Besitzer verrät oder will man wirklich verhindern, das auch Spezialisten die eine Menge Aufwand treiben können sich die Zähne daran ausbeissen. Je mehr Schutz man möchte, umso höher ist dann eben auch der Preis in Form von Performanceverlust, den man dafür bezahlen muß.
 
Ohne eine Diskusion über die Begründung zu starten:
Für mein System benötige ich einen "erweiterten Schutz", zumindest dem nach AES256 Standard.
(Der auch eigentlich bei einem guten Paswort sogar gegen Spezialisten reichen dürfte/müsste)

Richtig TRIM wird (nur) bei einem versteckten Betriebsystem nicht unterstützt.
Fürs erste würde ich aber erstmal die reine ("normale") Vollverschlüsselung nutzen.
Sprich, System-Partition ist verschlüsselt, der Boot-Loader im Klartext vorhanden.


Was hat es eigentlich mit dem Gerücht auf sich, die Partition einfach kleiner zu halten;
Umso die möglichen Perfomance-einbußungen bei vollgeschriebener Platte zu umgehen ?

Ein somit auf allen Seiten abgestimmtes Szenario wäre dann ja, theoretisch:
Klartext Bootloader + (Highend-)Verschlüsselte Partition + Restlicher unpartionierter Bereich.
Allerdings müsste dann TRIM deaktivert werden, was wiederum zum Einbruch führt... richtig ?

Was haltet ihr davon ?
 
Zuletzt bearbeitet:
X373N schrieb:
Was hat es eigentlich mit dem Gerücht auf sich, die Partition einfach kleiner zu halten;
Umso die möglichen Perfomance-einbußungen bei vollgeschriebener Platte zu umgehen?
Das ist kein Gerücht sondern für System ohne TRIM eine sinnvoll Massnahme um den Schreibperformanceeinbruch zumindest für Dateien zu vermeiden, die nicht größer als die Spare Area sind und es erhöht halt auch die Lebendauer da es die Writeamplification verringert.

Hier habe ich das gerade erst erklärt und über TRIM habe ich hier mal was geschrieben. Ist keine leichte Kost, aber das Thema ist ja auch komplex.
 
Okay langer, Text kurzer Sinn.
Ich denke ich habe die Funktion von TRIM verstanden.
(Kann man wohl fernerweise mit Defragmentierung vergleichen)
Der letzte Abschnitt sagt ja das mit "Secure Erase" (Ich lösche NUR so),
der kompletten Platte die Perfomance wiederhergestellt wäre.

Die Frage bleibt dann ob aktiviertes TRIM in dieser verschlüsselten Partition ein Sicherheitslag ist.
Wenn ich das richtig verstanden habe werden die Daten temporär unverschlüsselt abgelagert.. ?

Allerdings wurde nicht ganz Klar was die Lebensdauer betrifft, da nicht pauschalisiert werden könne.
Wie verhält es sich denn da mit der M4 60GB also auch den eigenen Controller ?
 
Zuletzt bearbeitet:
X373N schrieb:
Wenn ich das richtig verstanden habe werden die Daten temporär unverschlüsselt abgelagert.. ?
Nein - zumindest nicht bei TrueCrypt, da ich hier den Quelltext kenne. Das Sicherheitsrisiko bezieht sich nur darauf, dass ungenutzte Bereiche der Partition als Nullblöcke sichtbar sind und dadurch die genutzten von den ungenutzten Bereichen unterschieden werden können. Dies ist jedoch noch lange kein kritisches Sicherheitsrisiko.

X373N schrieb:
Allerdings wurde nicht ganz Klar was die Lebensdauer betrifft, da nicht pauschalisiert werden könne.
Bezüglich Lebensdauer kann man wirklich so gut wie nichts vorhersagen - das hängt von viel zu vielen Faktoren ab. Fakt ist, es werden bei einer vollen SSD mehr Daten geschrieben als bei einer nicht vollständig gefüllten - um wie viel das die Lebensdauer verringert ist jedoch nicht direkt ersichtlich. Interessant sind hier auch die Tests von einem Forum, dort haben eigentlich so gut wie alle SSDs über 200TB geschrieben.
 
X373N schrieb:
Okay langer, Text kurzer Sinn.
Ich denke ich habe die Funktion von TRIM verstanden.
(Kann man wohl fernerweise mit Defragmentierung vergleichen)
Nur ganz entfernt.
X373N schrieb:
Der letzte Abschnitt sagt ja das mit "Secure Erase" (Ich lösche NUR so),
Das glaube ich nicht, denn Secure Erease löscht alle Daten auf der SSD, was Du machst ist Wipe, also Überschreiben der Daten bevor diese wirklich gelöscht werden. Das funktioniert bei SSDs aber nicht, weil diese ja die LBAs auf eine andere Flashadresse gemappt werden müssen, wenn die überschrieben werden (sonst müssten die Blöcke erst gelöscht werden was langsam wäre und Wearleveling ginge auch nicht). Das solltest Du bei einer SSD also niemals machen!
X373N schrieb:
der kompletten Platte die Perfomance wiederhergestellt wäre.
Dazu muss aber ein Secure Erease auf die ganze SSD ausgeführt werden, also z.B. mit HDDErase oder gparted. Danach sind natürlich alle Daten weg!

Wenn Du bisher kein TRIM aktiviert hattest und immer mit einen Wiper Deine Daten gelöscht hast, der diese auch noch mehrfach überschreibt, dann ist es in der Tat möglich, dass die Schreibrate der m4 eingebrochen ist oder so gering ist, weil der Wiper bei den Schreibtests eben immer mit anspringt und die Dateien vor dem Überschreiben/löschen durch den Benchmark selbst noch mal wippt. Stell das Teil sofort ab.

X373N schrieb:
Die Frage bleibt dann ob aktiviertes TRIM in dieser verschlüsselten Partition ein Sicherheitslag ist.
Wenn ich das richtig verstanden habe werden die Daten temporär unverschlüsselt abgelagert.. ?
Wenn Deine Partition auch noch verschlüsselt ist, dann brauchen wir und gleich garnicht mehr über die Schreibperformance zu unterhalten. Die hängt dann natürlich nicht mehr so sehr von der SSD selbst ab. Man Verschlüsselungen belegen die ganze Platte mit Daten und lassen kein TRIM durch. Damit ist die SSD dauernd voll und wird ständig gefoltert, weil die überhaupt keine freinen Flashadressen außerhalb ihrere Spare Area hat. Das ist dann genau die Situation wie die bei Anandtech vorliegt.
X373N schrieb:
Allerdings wurde nicht ganz Klar was die Lebensdauer betrifft, da nicht pauschalisiert werden könne.
Wie verhält es sich denn da mit der M4 60GB also auch den eigenen Controller ?

Wie man im Dauerschreibtest auf xtremesystems.org sieht, ist die Lebensdauer der m4 normalerweise kein Problem. Wenn man sie aber derart misshandelt, wird die klar kürzer ausfallen.
 
- Also kein wirkliches Sicherheitsrisiko durch verkleinern der Partition, okay das ist gut. :)
- Momentan habe ich die SSD (samt Rechner) nocht nicht bestellt:
Ich meinte, das ich generell (also momentan bei der HDD, beim einzelnen Löschen sowohl auch formatieren, Wipe nutze. (Überschreiben der gesamten Platte (nicht nur Index) mit Zufallsweten,bei der HDD 7x mal, die SSD brauch ja nur einmal) Also jedesmal wenn ich das System neu einrichte, (alle 3 Monate ca.) formatiere ich zuvor die Platte 7x komplett. Mit der SSD und TrueCrypt würde ich dann generell weniger formatieren, also jeweils selten und nur für die Perfomance. Im Betrieb reicht dann sowieso nur "normales" löschen einzelner Dateien damit diese "weg" sind, richtig ? (Bzw. wie du ja schon angesprochen hast, käm mehrfaches überschreiben der SSD sowieso mal garnicht gut.)

- Nein TRIM wird bei Vollverschlüsselung der Boot-Partition von Truecrypt unterstützt, wurde ja bereits geklärt :) (Ledeglich bei einem komplett versteckten Betriebsystem - also nicht nur Verschlüsselte Partition, nicht)

- Und die Platte wird bei einer verschlüsselten Boot -Partition nicht komplett beschrieben. Im Boot-Sektor kommt der Loader rein, und die Partition selbst (also abhängig ihrer Größe) wird komplett beschrieben. (Also unabgängig wieviel Daten wirklich Platz brauchen, - Der rest, also unpartionierter Bereich, bleibt unbeschrieben.)

Also Zusammenfassugn der Beiträge hier wäre:
Bei einer Truecrypt Verschlüsselte Boot-Partition (offenes Betriebsystem, nicht versteckt)
- mit kleinerer Ausmaße = Kleinere Perfomance - Einbußungen.
- mit aktivierten TRIM = Perfmance Erhaltung + Kein wirkliches Sicherheitsrikiko.
- mit deaktiverten TRIM = Perfomance Erhaltung benötigt ab und zu Seure Erase der gesamten SSD.
- ist die Lebenserwartungszeit unklar.

Wieviel darf denn da von der Platte genutzt werden damit diese keine Perfomance Probleme hat ?
Oder lässt sich sagen das es proportional umso mehr beschrieben ist, auch schlechtere Perfomance ergibt sich?
 
Zuletzt bearbeitet:
Wenn Du sowas einsetzt, dann wirst Du keinen sehr großen Vorteil aus der SSD ziehen, dann die kann ihre Performance ja kaum ausspielen. Überschreiben bringt bei einer SSD auch nicht, deswegen braucht man es nicht 7xmal und auch nicht einmal zu machen, einfach löschen und ein aktives TRIM reichen aus und die SSD wird die Daten dann auch irgendwann wirklich aus dem Flash entfernen. Tue Dir einen Gefallen: Verschlüssel nur auf Dateieeben aber nicht auf Partitionsebene! Wenn Du das doch machen willst dann kaufe die SSD am besten doppelt so groß und lasse die Hälfte unpartitioniert, sonst ist keine Performance so wie um Bild der gefolterten m4 von Anandtech:
m4-0009-torture_575px.png

Lässt Du die Hälfte frei, so schiebst Du den Einbruch der Schreibrate auf die Hälfte der Kapazität heraus, die Du soweiso nicht nutzen kannst (weil unpartitioniert) und erhälst neben der volle Schreibperformance auch die Lebensdauer einigermassen aufrecht. Der Einbruch erfolgt ja deswegen, weil der Controller ab da haufenweise Daten umkopieren muß, von denen er eben wegen des fehlenden TRIM nicht erfahren hat, dass diese schon ungültig sind (was ja das gleiche ist wenn die Partition selbst komplett beschrieben wird und man TRIM somit aushebelt). Das erzeugt halt eine gewaltige Writeamplification von locker über 100 wenn nur wenige % Spare Area vorhanden sind wie es aber Werk der Fall ist und senkt daher die Lebensdauer drastisch.
 
Zuletzt bearbeitet:
Okay jetzt bin ich komplett verwirrt...

Was genau sollte ich nicht einsetzten ?
Und ich darf nur 50% nutzen, ansonsten bricht die Leistung gegen Null ???
Das dürfte ja dann alle SSD Besitzer betreffen und das kann ja nicht sein..

Also wie erwähnt das Szenario lässt TRIM problemlos zu.
Wie auf den vohrigen Seiten erklärt wird mach TrueCrypt der Perfmance wenig.
http://www.hardwareluxx.de/communit...crypt-vs-bitlocker-vs-diskcryptor-689181.html
Hier wird ja auch nur 20% Freigelassen und die Werte sind und bleiben sauber.

Löschen auch wie bereits nur bei der HDD 7x, die SSD wie die auch sagts nur einmal reicht.
Also ich versteh jetzt nicht wie und unter welchen Bedingungen die SSD in den Bach geht.
Mit TRIM ist doch alles in Butter...

Sorry vielleicht verstehe ich da was nicht so recht.
Beachte ich bin da wirklich ein Laie..

Also wie muss das ganze eingerichtet um rundum abgedeckt zu sein ?
Sprich Truecrypt Verschlüsselung nutzen dabei Leistung, und Lebenszeit halbwegs oben zu halten.

Also defintiv werde ich eine 60GB Platte haben und Truecrypt nutzen wollen.
 
Zuletzt bearbeitet:
X373N, wenn die ganze Partition immer gefüllt gehalten wird, dann ist die SSD eben immer voll und TRIM spielt auch keine große Rolle mehr, denn TRIM verschiebt ja nur den Zeitpunkt, wann der Controller weiß, ob Daten ungültig sind. Mit TRIM weiß er dass, wenn eine Datei gelöscht wird und ohne TRIM erst, wenn das Filesystem die LBAs wieder überschreibt. Überscheibt die Software aber die LBAs sofort wieder um die Partition immer voll zu halten und keinen Hinweis auf die wirklich belegten Bereiche zu geben, so bringt TRIM eben nichts mehr, der Zeitpunkt wird ja kaum noch verschoben.

Damit die Performance eben nicht einbricht mußt Du soviel Platz unpartitioniert lassen (gleich wenn die SSD neu ist), wie Du eben schnell schreiben können willst. Bei 50% unpartitionierten Platz bleibt die Performance dann eben über die ganze genutztet Kapazität erhalten, bei 20% bricht die Schreibleistung dann ein, wenn Du mehr als ein Viertel der Partiton auf einmal beschreibst, obendrein leidet die Lebensdauer stärher, weil die Writeamplification dann höher ist, die SSD ist ja immer zu 80% gefüllt.

Wenn Du also eine 60GB SSD und Truecrypt nutzen willst, dann solltest Du niht mehr als 40GB Platz brauchen oder eine größere SSD nehmen, etwa die Kingston SSDNow V+ 100 96GB, denn die Performance wird sowieso leiden, die IOPS ebenso und damit macht es dann weniger aus, dass die Kingston langsamer ist und Du hast mehr von deren höhrere Kapazität.
 
X373N schrieb:
Also wie muss das ganze eingerichtet um rundum abgedeckt zu sein ?
Sprich Truecrypt Verschlüsselung nutzen dabei Leistung, und Lebenszeit halbwegs oben zu halten.

Also defintiv werde ich eine 60GB Platte haben und Truecrypt nutzen wollen.

Also wenn ich mir das so anschaue: http://www.hardwareluxx.de/community/17267231-post182.html
dann würde ich definitiv nicht TrueCrypt, sondern DiskCryptor für die SSD verwenden. Ist auch eine Open-Source Verschlüsselung, und sollte somit die selbe Sicherheit bieten.

Desweiteren wäre ein Intel Prozessor mit AES-NI sehr empfehlenswert, der AES in TrueCrypt und DiskCryptor hardwaremäßig unterstützt, und so eine hohe Verschlüsselungsleistung ohne große CPU-Belastung bietet.

Wenn dein System voll verschlüsselt ist, dann brauchst du übrigens kein sicheres Löschen. Die Daten auf der HDD sind auch so komplett unlesbarer Schrott, wenn man sie nicht entschlüsseln kann. Und das ist bei AES bisher noch keinem gelungen.

Einige Prozent (mind. 10) auf der SSD frei zu lassen (nicht zu partitionieren) wäre für gute Leistung sicher angebracht, da der partitionierte Bereich einer verschlüsselten Partition eben "voll" ist, ob da nun wirklich Daten drauf sind, oder nicht.
 
Bei einer Verschlüsselten Partition ist der Inhalt nur von außen voll beschrieben, nicht von innen.
Im Betrieb selbst gibts es freie Bereiche also somit auch freie Blöcke oder spielt das keine Rolle ?

Damit die Performance eben nicht einbricht mußt Du soviel Platz unpartitioniert lassen (gleich wenn die SSD neu ist), wie Du eben schnell schreiben können willst. Bei 50% unpartitionierten Platz bleibt die Performance dann eben über die ganze genutztet Kapazität erhalten, bei 20% bricht die Schreibleistung dann ein, wenn Du mehr als ein Viertel der Partiton auf einmal beschreibst, obendrein leidet die Lebensdauer stärher, weil die Writeamplification dann höher ist, die SSD ist ja immer zu 80% gefüllt.

Aber ich schreib doch nie im Leben 30GB auf einmal selbst keine 10, die Platte bleibt doch so.
Wenn die einmal mit dem OS beschrieben ist, verändert sich doch nur in wenigen MB etwas.
Ich versteh das Verhältniss zwischen Kapazität und Perfomance nicht...

Der eine sagt 50%, der andere sagt 10% reichen.. ja was denn nun ???
Und wie man auf den Bildern von etheReal geposteten Link erkennt;
gibt es doch nur wenig Einbrüche im allgemein.
Wieso dann eine nochmals 100mb/s schreib-langsamere SSD nehmen ??

@etheReal
- Ja, als ich mir die hinteren Post so angeschaut hab,
wollte ich hier auch fragen ob DiskCryptor vielleicht nicht besser wäre.
- Wie im ersten Post erklärt werde ich einen AES-NI fähigen Prozessor nutzen. :)
(Grade größtenteils wegen AES-NI habe ich mich auch auf den i5-2400 entschieden.)
- Nunja im Betrieb selbst (also entschlüsselt) ließe sich die Datei wiederherstellen.
Daher auch dort einfach sicheres löschen bzw einmaliges - was bei SSD ja höchste Sicherheit entspricht.
(Ich weiß, man könnte philosofieren ob mans braucht, aber sagen wir so - ich will es lieber so.)

Wie wird denn innerhalb der Partition TRIM ausgeführt ?
Wenn physikalisch ist der Danteträger besetzt, Virtuell aber nicht...
Wenn wir jetzt Defragmentierung als Vergleich nehmen: Hier macht es sich bezahlt.
 
X373N schrieb:
Bei einer Verschlüsselten Partition ist der Inhalt nur von außen voll beschrieben, nicht von innen.
Innen und Außen gibt es nicht, nur für das Filesystem und für das Laufwerk. Für das Filesystem ist die verschlüsselte Partition frei, für die SSD ist sie aber voll, denn alle LBAs der Partition werden ja von der Software beschrieben. Damit bleibt nur die normaler Spare Area der SSD auf die sie Daten schreiben kann ohne vorher erst umkopieren und löschen zu müssen, was das ganze sehr langsam macht, siehe auch hier.

X373N schrieb:
Im Betrieb selbst gibts es freie Bereiche also somit auch freie Blöcke oder spielt das keine Rolle ?
Für das Filesystem ja, aber für den SSD Controller eben nicht. Eine HDD kann man ja einfach überschreiben, aber bei einer SSD geht das nicht und deshalb speichert der Controller die Daten erstmal auf andere, freie Adresse und die sind eben umso knapper, je voller die SSD ist, was in diesem Fall je mehr Platz auf der SSD von der verschlüsselte Partition belegt wird. Gleichzeitig sinkt damit auch die Lebensdauer, weil sich die Writeamplification zwangsläufig erhöht, hier mehr darüber wieso das so ist.

X373N schrieb:
Aber ich schreib doch nie im Leben 30GB auf einmal selbst keine 10, die Platte bleibt doch so.
Bei einer HDD ja, die bleibt so, eine SSD arbeitet aber anders und muß den freien Platz entweder haben oder ihn sich schaffen und dabei fällt die Performance und sinkt die Lebensdauer, weil eben eine Menge Daten umkopiert werden müssen, von denen der Controller eben nicht wissen kann, ob diese nun gültig sind oder nur deshalb beschrieben wurde, um nicht die Größe der wirkliche Daten preiszugeben. Deshalb ist es besser für die SSD, wenn man nur die Dateien verschlüsselt und nicht die ganze Partition.
X373N schrieb:
Wenn die einmal mit dem OS beschrieben ist, verändert sich doch nur in wenigen MB etwas.
Ich versteh das Verhältniss zwischen Kapazität und Perfomance nicht...
Lies mal den oben von mit verlinkten Beitrag über TRIM und GC, dann wird Dir hoffentlich klarer, wie ein SSD Controller arbeitet.

X373N schrieb:
Der eine sagt 50%, der andere sagt 10% reichen.. ja was denn nun ???
Das hängt davon ab, wieviel Daten Du normal so drauf speichern willst, wenn sich bei Dir täglich nur wenig ändert, dann kannst Du weniger freihalten. Je weniger Du aber freilässt, umso mehr leidet die Lebensdauer.

X373N schrieb:
Und wie man auf den Bildern von etheReal geposteten Link erkennt;
gibt es doch nur wenig Einbrüche im allgemein.
Wieso dann eine nochmals 100mb/s schreib-langsamere SSD nehmen ??
Weil Du bei der für kaum mehr Geld 50% mehr Kapazität bekommen wirst und somit mehr freilassen kannst. Die seq. Transferraten und vor allem auch die Randomwerte leiden unter der Verschlüsselung sowieso, wenn Du maximal Performance haben willst, dannn darfst Du die SSD eben nicht verschlüsseln.
X373N schrieb:
Wie wird denn innerhalb der Partition TRIM ausgeführt ?
Wenn die LBAs auf denen die Datein lag gleich wieder überschrieben werden, dann ist TRIM egal, das habe ich doch oben schon geschrieben. Wennn die Verschlüsselung die ganze Partition immer belegt hält, dann spielt TRIM auch keine Rolle, denn beim Überschreiben passiert ja genau das gleiche wie bei TRIM: Der Controller erfährt das die alten Daten jetzt ungültig sind.
 
Performance-Verlust mit

a) TC

-> sequ=ungefähr 0, random-read-4k=40% bei einem i5-750@4Ghz, AES-NI bringt NICHTS um diesen Bereich zu beschleunigen, auch das wurde schon in den hier verlinkten Threads getestet.

b) DC

-> sequ.= leicht geringer als TC (statt 250MB/s read nur noch 230-240MB/s), random-read-4k=rund 10% bei einem i5-750@4Ghz.

Die derzeitige beta-Version dieses Programms läuft seit Monaten bei mir stabil. Davor hatte ich Truecrypt und auch keine Probleme bzgl. Stabilität.

c) Fazit

Sehr schwer...es ist ja so, dass viele (Experten) behaupten, dass das Erreichen von mehr als 10MB/s im random-read-4k keine merkbaren Performance-Vorteile mehr bringt. Das kann schon sein, ich lass das einfach mal so stehen. Fühlt sich aber trotzdem doof an, wenn bei TC im AS-SSD Benchmark die Punkte von 440 auf 170 runtergehen. Bei DC bleiben die Punkte nahezu auf dem Maximum, vielleicht 5 oder 10 Punkte weniger. Zudem kann ich hier sicher sein, dass die SSD nicht limitiert wird. Höhere 4k Werte können ja auch nicht schaden. Bei DC gibt es dafür ein deutlich kleineres Forum und keine Rettungs-CD (obwohl man auch hier einiges zur eventuellen Datenrettung vorbereiten kann). Dafür ist die Wahrscheinlichkeit höher, dass eventueller Schad-Code (Trojaner, Boot-Logger, etc.), der aufgrund der Popularität für TC geschrieben wurde, bei DC nicht funktioniert.

Zur Lebensdauer noch schnell...Benutze meine SSD jetzt mehr als 1 1/2 Jahre nur vollverschlüsselt, erst TC, jetzt DC, schone sie kein bißchen und komme jetzt auf etwas über 3,5 TB. Rechnet man das mal auf die schon genannten Ergebnisse im xtremesystems-Forum hoch, dann kommt man locker auf über 50 Jahre Nutzung...
 
Vielen Dank erst nochmal für die Erklärungen..
Mhh, also ich hatte diesen verlinkten "Erklärungsversuch" ja schonmal gelesen.
Nun nochmals und alle die Verlinkten Threads auch komplett durch gelesen.
Also so annhäern versteh ich wie eine SSD arbeitet, aber es mir immernoch eindeutig zu komplziert.
Ich habe mir aber von Wikipedia mal ein paar Begriffe übersetzten lassen.
Siehe da es lässt sich besser verstehen, aber ich gebs trotzdem auf...

Also LBA nennt sichja die Verwaltungsmethode der Daten auf der Platte.
Davon gibts nunmal aber auch nur eine und nicht mehrere sprich LBAs.
Wenn du von LBAs schreibst meintest du eigentlich die zu addressierten Blöcke, richtig ?

Wie ich das verstehe ist diese sogenante Spare-Area aber doch genau für den angesprochen Bereich eingerichtet ?
Andere Hersteller geben ihre Platten ja mit 60GB an, heißt sie hat Physikalisch eigentlich 64GB, mit entsprechenden Bereich.
Das würde bedeuten das wie hier von anderen angenommen auch nur c.a 10% also in den fall etwas mehr vollkommen reichen.
Also für den Fall das sie keine bzw zu kleinen Bereich hat, diesen dann auf ca 50GB zu limierteren.

Aber wenn die Daten doch umkopiert werden müssen, sprich in den Spare-Bereich sind diese doch im Klartext zu sehen oder ?
Also hat doch das ganze mit der Verschlüsselung keinen Sinn mehr, da aufgrund Platzmangels IMMER ausgewichen werden muss ?!

Also wie gesagt ich werd aus dem Thema einfach nicht schlau..
Daher nimmst mir bitte nicht Übel wenn ich nun pauschal frage:

- Meine Partition benötigt ungefähr 40-50GB, wieviel muss/soll ich also "frei lassen" ?
- Werden die Daten beim umkopieren nun im klartext geschrieben oder nicht ?
- Also wäre TRIM so oderso egal, hauptsache ich lass etwas frei, richtig ?

@stw500

Also nochmal übersetzt:
Mit TC gibt es nur einen (angeblich nicht merkbaren) Verlust von 40% im random-read-4K Bereich ?
Mit DC gibt es nur einen Verlust von c.a 20MB/s im sequenziellen lesen, und 10% Verlust bei RR4K ?

Also mit anderen Worten keine nennenswerten Unterschiede..

Wie groß is denn deine Partition bzw der unpartionierte Bereich ?
Also wie hast und hattest du das ganze eingerichtet bei TC und nun DC ?
Hast du auch eine 64GB Crucial M4 ?

Weiß du zufällig ob DC auch die features von TC anbeitet, zB einen Custom-Bootloader ?
 
Zuletzt bearbeitet:
X373N schrieb:
Also LBA nennt sichja die Verwaltungsmethode der Daten auf der Platte.
Davon gibts nunmal aber auch nur eine und nicht mehrere sprich LBAs.
Wenn du von LBAs schreibst meintest du eigentlich die zu addressierten Blöcke, richtig ?
LBA steht für Logical Block Adress und ist die Adresse eines logischen "Sektors" einer Platte. Damit Windows funktioniert, muß diese Sektor genau 512Byte umfassen, wie es eben jahrzehntelange auch die Größe eines physikalischen Sektors auf einer HDD war. Zu Beginn wurden HDDs einfach in Tracks (die Ringe oder Spuren einer HDD) eingeteilt und diese wieder in Spuren unterteilt. Hat man mehr als einen Schreib- Lesekopf, so kommt auch noch der Kopf hinzu und schon konnte man jedes Byte der HDD adressieren und so wurde es aber früher auch noch gemacht. Man braucht also damals im BIOS die Informationen: Anzahl der Köpfe, Tracks (Spuren) und Sektoren pro Track.

Nur sind die äußeren Spuren ja viel größer als die inneren Spuren, man kann diese also in mehr Sektoren unterteilen und damit auch mehr Daten darauf unterbringen, ohne dass die Daten dafür dichter gepackt werden müssen. Damit wird aber die Anzahl der Sektoren pro Track eine Funktion in Abhängigkeit vom Track und ist keine Konstante mehr. Zusätzlich kommt noch hinzu, dass jede SSD da wieder andere Werte verwendet und sich die Anzahl der Sektoren alle paar Tracks ändert.

Für den Rechner selbst wäre damit eine genau Berechung der Position kaum noch möglich gewesen und so hat man diese Logik in den Controller der HDD ausgelagert, brauchte aber nun eine neue Adressierung für die Sektoren. Der Einfachheit halber hat man diese also einfach durchnummeriert und nennt diese Nummer die Logische Block Adresse (LBA). Somit stellt jede (SATA) Platte heute eben eine bestimmte Anzahl an LBAs zur Verfügung, man könnte auch x Sektoren sagen. Zumindest bis vor kurzem, denn seid es die HDD mit Advanced Format gibt, die physikalisch 4k Sektoren haben, wird bei denen jeder 4k Sektor in 8 LBAs unterteilt (die simulierten 512Byte Sektoren), denn Windows kommt nur mit 512Byte als kleinste Einheit eines Platte klar.

Sektor wird obendrein auch als Name für den Cluster eines Filesystems (bei NFTS überlicherweise 4k, man kann es beim Formatieren aber i.d.R. auswählen) verwendet. Wählt man beim Formatieren einer Advanced Format HDD jetzt 8k große Cluster, so gibt es drei verschiedene Dinge die alle Sektor genannt werden können und alle unterschiedlich groß sind:

1. Der pyhsikalische Sektor der Disk: 4k
2. Der Logisch zu adressierenden Sektor der Disk, der LBA mit 512 Byte
3. Der Sektor im Filesystem, desshalb auch Cluste genannt weil der mehrere auseinander folgenden LBAs der Disk belegt mit 8k

Du siehst also, von Sektoren zu reden ist Problematisch, zumal die SSDs ja keine physikalischen Sektoren wie die HDDs haben, sondern Pages als kleineste sinnvolle Verwaltungseinheit die gelesen bzw. geschrieben werden kann. Damit haben wir bei einer SSD also:

1. Die Pagesize
2. Den LBA als Adresse, unter der das Filesystem die Daten ablegt
3. noch immer den Cluster des Filesystems

Wenn ein phy. Sektor nicht defekt ist und durch eine Reservesektor ersetzt wurden, so braucht der Controller einer HDD den Adresse (LBA) nur in Spur, Kopf und Sektor umzurechnen und wird für eine LBA immer auf das gleiche Ergebniss kommen. Bei jeder Umdrehung kommt der Sektor dann einmal unter dem Kopf vorbei und kann gelesen oder beschrieben werden, so oft man will.

Der Controller eines SSD wandelt eine Adresse (LBA) in eine Flashadresse um, die sich nach Kanal, Die auf dem Kanal und Pagenummer und Offset in der Page unterscheidet. Lesen kann er diese Page auch so oft er will, aber er kann sie eben nicht einfach neu beschreiben. Vor dem neuen Beschreiben muss die Page gelöscht werden und selbst dass geht nicht einfach so, denn es müssen immer eine Menge (128, 256, 512 oder nochmehr) Pages auf einmal gelöscht werden. Dies kleinste zu löschbare Einheit nennt man einen Block.

Die Anzahl dieser Löschvorgänge ist aber bei Flashspeicher aber begrenzt und deshalb löscht der Controller eben nicht einen ganze Block, nur weil eine Page darin überschrieben werden soll. Damit wäre nicht nur der Verschleiß gewaltig hoch, sondern auch die Geschwindigkeit sehr schlecht, denn in den anderen Pages das Block können ja auch noch Daten stehen und die müssen vor dem Löschen alle gelesen und wieder geschrieben werden. Deshalb schreibt der Controller die neuen Daten also besser an eine andere Adresse im Flash in einen noch freien Block und kennzeichnet die Daten an der alten Flashadresse als ungültig. Damit das geht, kann er aber eben die Adressen nicht einfach so umrechnen wie der Controller eine HDD sondern muß eine Tabelle führen wo die Daten zu jeder logischen Adresse (LBA) im Flash liegen, was man Mapping nennt.

Hat der Controller jetzt nur noch wenige freie Pages zum schreiben zu Verfügung, dann muß er sich wieder neue schaffen. Dazu schaut er sich an, in welchen Blöcke keine oder möglichst wenige Pages mit noch gültigen Daten belegt sind. Dies noch gültigen Daten werden dann in die noch freien Pages kopiert und der Block wird gelöscht, was dann wieder freie Pages ergibt. Je mehr Daten dabei kopiert werden müssen, umso höher ist die Write Amplification, denn diese Daten ja nur einmal auf die SSD geschrieben, werden aber dann schon zum zweiten mal ins Flash geschrieben. Die Writeamplification ist nicht anderes als das Verhältnis der im Flash geschrieben Daten zu den auf die SSD geschrieben Daten.

Je voller eine SSD ist, umso öfter muß der Controller also auch Blöcke löschen in denen noch mehr Pages mit gültige Daten liegen und damit steigt die Writeamplification. Eine hohe Writeamplification bedeutet aber eine schlechtere Lebensdauer. Damit der Controller nicht erst beim Schreiben von Daten mit dem Löschen und ggf Kopieren anfangen muß, hält er eben möglichst immer eine Menge an freien Pages vor, je mehr er vorhält umso mehr Daten wird er dazu auch kopieren müssen.

Werd nun also bei der verschlüsselten Partition die Adressen auf denen gelöschte Dateien lagen ständig wieder überschrieben, so ist die SSD immer ständiug mit gültigen Daten (aus Controllersicht) im Volumen der Größe der Parition gefüllt. Somit kann der Controller nur Speicherbereiche zum Vorhalten freier Pages verwenden, die eben nicht von der Partition belegt sind. Belegt die Partition aber den geamten adressierbaren Bereich (= alle LBAs der SSD), so sind das nur wenige Prozent der Flashkapazität. Diese wenigen Prozent dürfte also mit ungültigen Daten belegt sein oder müssen als freie Pages vorgehalten werden. Entscheidet der Controller möglichst viele davon als freien Platz vorzuhalten, so wird die Writeamplification sehr hoch ausfallen und entscheidet er sich diese zu vermeiden und die ungültigen Daten darin zu belassen, so wird die Schreibgeschwindigkeit sehr gering ausfallen. Das passiert auch dann zwangsläufig, wenn der freie Bereich vollgeschrieben wurde.

Deshalb gibt: Wenn die ganze Partition verschlüsselt wird und die Sicherheitssoftware die Dateien gleich wieder üerschreibt um die wahre Größe/Position der sinnvollen Daten auf der Disk zu verschleiden, dann sollte man einen Teil der neuen SSD (oder nach Secure Erease) gleich unparitioniert lassen, je mehr je besser!

X373N schrieb:
Wie ich das verstehe ist diese sogenante Spare-Area aber doch genau für den angesprochen Bereich eingerichtet ?
Andere Hersteller geben ihre Platten ja mit 60GB an, heißt sie hat Physikalisch eigentlich 64GB, mit entsprechenden Bereich.
Der Unterschied zwischen Flashgröße und der nutzbaren Größe wird nicht nus als Spare Area für Nutzerdaten verwendet. Verwaltungsdaten wie das Mapping der LBAs auf Flashadresse müssen dort auch untergebracht werden. Bei Sandforce Controller legt deren Fehlerkorrektur RAISE immer auf eigens reservieren, ganzen Die seine Prüfsummen ab, das entfällt somit komplett für Userdaten und u.a. deshalb haben die auch immer weniger Kapazität also die meißten anderen SSDs.

Diese stärkere Fehlerkorrektur ist zwar eingentlich ein Vorteil des Sandforce, ermöglicht es den SSD Herstellern aber auch minderwertige NANDs zu verbauen ohne gleich Probleme deswegen zu bekommen, später hat dann aber der Kunde den Ärger.

X373N schrieb:
Das würde bedeuten das wie hier von anderen angenommen auch nur c.a 10% also in den fall etwas mehr vollkommen reichen.
Also für den Fall das sie keine bzw zu kleinen Bereich hat, diesen dann auf ca 50GB zu limierteren.
Jede SSD hat auch einen Bereich frei für Nutzerdaten, aber eben sicher keine 10%. Die Nutzung einer in einem Zustand in dem sie für den Controller immer voll ist, stellt den allerschlimmsten denkbaren Nutzungszustand dar. Deshalb sollte man ihr da gleich mal mehr freien Platz lassen und dies geht nicht durch nachträgliches Verkleinern der Partition!

X373N schrieb:
Aber wenn die Daten doch umkopiert werden müssen, sprich in den Spare-Bereich sind diese doch im Klartext zu sehen oder ?
Nein, die Dateien werden ja auch verschlüsselt, im Klartext sehen sie bei Verschlüsselung niemals im Flash, sie werden aber eben auch nicht im Flash überschrieben, wie das eben bei einer HDD der Fall wäre. Deswegen ist es ja auch unnötig die ganze Partition zu verschlüsseln und reicht vollkommen nur die Dateien alle zu verschlüsseln. Dann ist die Partition ja auch nicht mehr dauernd voll für den Controller, TRIM wirkt wieder und man braucht auch nicht extra Platz freizulassen, denn für den Controller ist sie dann (mit TRIM) nur genauso voll wie für das Filesystem.

X373N schrieb:
Also hat doch das ganze mit der Verschlüsselung keinen Sinn mehr, da aufgrund Platzmangels IMMER ausgewichen werden muss ?!
Sage ich ja die ganze Zeit, Verschlüsselung auf Partitionseben ist bei SSDs nicht sinnvoll, denn man kann die Daten eben einfach nicht im Flash selbst überschreiben wie dies bei einer HDD geht.

X373N schrieb:
Also wie gesagt ich werd aus dem Thema einfach nicht schlau..
Doch, Du fängst schon an zu Begreifen, damit ist meine Schreiberei hier nicht umsonst!
X373N schrieb:
Daher nimmst mir bitte nicht Übel wenn ich nun pauschal frage:
- Meine Partition benötigt ungefähr 40-50GB, wieviel muss/soll ich also "frei lassen" ?
Wenn Du 50GB brauchst, dann hast Du bei einer 64GB oder gar einer 60GB SSD nicht mehr viel Spielraum und kannst nicht viel mehr als so 5GB bis 6GB freilassen. Deshalb ist die 96GB Kingston für Dir vermutlich die bessere Wahl, bei der kannst Du 1/3 (30GB) freilassen und hast immer noch 60GB zur Verfügung, für nur 10€ mehr.
X373N schrieb:
- Werden die Daten beim umkopieren nun im klartext geschrieben oder nicht ?
Weil ja auch die Dateien selbst verschlüsselt sind: NEIN.
X373N schrieb:
- Also wäre TRIM so oderso egal, hauptsache ich lass etwas frei, richtig ?
Richtig, da die Software nach dem Löschen einer Datei die von ihr belegten Adressen sofort überschreibt erfährt der Controller sowieso gleich, wenn Daten ungültig geworden sind.
X373N schrieb:
@stw500

Also nochmal übersetzt:
Mit TC gibt es nur einen (angeblich nicht merkbaren) Verlust von 40% im random-read-4K Bereich ?
Mit DC gibt es nur einen Verlust von c.a 20MB/s im sequenziellen lesen, und 10% Verlust bei RR4K ?
Das wird Dir pauschal niemand sagen können, denn es hängt eben vom System ab.
X373N schrieb:
Also mit anderen Worten keine nennenswerten Unterschiede..
Du vergisst das Schreieben, was bei normalen Systemlaufwerken je nach Nutzung so 20 bis 40% der Datentransfers ausmacht!
 
Zur Performance mit TrueCrypt oder DiskCryptor kann ich nichts genaues sagen, da ich Bitlocker nutze. Vielleicht trotzdem nicht ganz uninteressant:

Unverschlüsselt (1 Kern Prime):
3.png

AES-128 mit Diffuser (1 Kern Prime):
2.png

AES-256 mit Diffuser (leider ohne Prime):
1.png

Das unverschlüsselte System hatte noch 60 GB Platz, mittlerweile sind noch 40 GB frei. Ich selbst nutze 128-Bit-Variante, das ist sicher genug.
 
Zuletzt bearbeitet:
Bitlocker ist halt proprietäre Software. Das nützt was gegen Diebe, aber wenn der CIA an deine Wikileaks Daten ran will, wer weiß, ob da nicht doch ein Backdoor in Bitlocker eingebaut ist... ;)
 
Da würde sich Microsoft ja ins eigene Bein schießen. Oder hast Du je gehört, dass eine Festplatte mithilfe dieser Backdoor entschlüsselt wurde? Was würde erst passieren, wenn diese Backdoor veröffentlicht würde? Das kannst Du vergessen, da ist keine Backdoor eingebaut.

Und AES ist nahezu unknackbar, da ist es auch egal, ob 128 oder 256 Bit. Der Atlantik lässt sich ja auch nicht einfacher durchschwimmen als der Pazifik.
 
Zuletzt bearbeitet:
Dionysos808 schrieb:
Da würde sich Microsoft ja ins eigene Bein schießen. Oder hast Du je gehört, dass eine Festplatte mithilfe dieser Backdoor entschlüsselt wurde? Was würde erst passieren, wenn diese Backdoor veröffentlicht würde? Das kannst Du vergessen, da ist keine Backdoor eingebaut.
Rein rechtlich hätte Microsoft wohl das Backdoor implementieren müssen, da es sich um eine US-Firma handelt. Angeblich hat es Microsoft jedoch nicht gemacht - der Quelltext ist zwar verfügbar, aber nur unter NDA: es darf also auch keiner Informationen darüber verbreiten. Ich hab allerdings schon gelesen, dass Bitlocker das Passwort temporär auf der HDD speichert - ich kann es mir jedoch nicht vorstellen.
 
Zurück
Oben