Ocz Vertex2 umtauschen & welche Ersatz?

Fast. Wenn ich unter W7 meine Eigenen Dateien dicht mache, flucht Windows bestimmt rum :D
(Nein da ist nichts drin. Es geht mir ums Prinzip^^)
 
Für sowas gibt es dateibasierende Verschlüsselung wie Bitlocker EFS.
 
Zuletzt bearbeitet:
Richtig. Home-Verzeichnis verschlüsseln kann Windows auch schon seit Urzeiten.
 
Nur viele Programme scheitern daran, wirklich ALLES User-bezogene im Homeverzeichnis zu speichern.
 
blafoo schrieb:
Punkt3: Swapt != /. Wenn du / hast hast du noch lange nicht nen Swap! Swap ist eine eigene Partition! Darüber reden wir gar nicht.
/ zu verschlüsseln ist vorgeschobene Paranoia und damit man sagen kann: uuiiii ich hab mein / verschlüsselt.
Zum Vergrößern anklicken....

Ich habe den Swapspace damit "erlegt" das ich nen LVM habe, dieses ist verschluesselt, darin liegen / und swapspace.

Und das hat weniger mit vorgeschobener Paranoia zu tun, sondern einfach "better safe then sorry." Ich sage ja auch nicht das es jeder so machen muss, oder das es der einzig richtige Weg ist. Und im zweifelsfall ist auch ne bash_history von root interessant. oder die /etc/shadow. oder die known_hosts vom root. Oder halt was in tmp liegt. Networkmanager ist auch geschwaetzig in den Logs. Es gibt genug dinge die _MICH_ dazu bringen zu sagen: lieber komplett / und gut ists. Aber wie gesagt, das ist ja jedem selbst ueberlassen.

Evil: 120 gig /, 4 GB swap, bisschen /boot und der rest das unverschluesselte. Also nichts konkret freigelassen, ausser das ich den Platz in / nicht ansatzweise aufbrauche. (180 gig sinds gesamt).
 
Den Rest deiner Argumente habe ich oben erlegt. /tmp /var mitverschlüssel .. passt .. aber warum bin files? Warum ausführbare dateien in /bin /usr/bin .. oder die Libs in /usr/lib /libs?

Und auch der NM schreibt fein nach /var/log .. ergo .. wenn /var/log verschlüsselt is is das Problem auch vom Tisch!

Daher das is vorgeschobene Paranoia und damit man sagen kann: ICh habe / verschlüsselt schaut an wie cool ich bin ;)

Was bringt es dir wenner /etc/shadow lesen kann? Einloggen kanner sich ja, dann findet ern leeren /home .. ui ui ui gefährlich!

Es bringt 0, außer böser Verslustleistung an der Geschwindigkeit.


Back zum Topic

Unter Win ist es aufgrund der Architektur wesentlich schwieriger das ganze zu realisieren. Leider ja.
 
Evilandi666 schrieb:
Da es verschlüsselt ist und dm-crypt kein trim unterstützt ist das für die SSD auch belegter Platz. ;)

Aber gut, eine nicht volle 60 GB Partition unverschlüsselt sollte ja reichen.
Zum Vergrößern anklicken....

Erst wenn er komplett beschrieben wurde. Nur durch das Anlegen von Partition, LVM und dmcrypt-Gedoens wirkt der fuer die SSD nicht voll, im Gegenteil :)
 
Achja .. dazu .. habe auf der Firma ne 30GB-Transcend-SSD .. die habe ich,warum auch immer .. als reiserfs formatiert .. kein Trim .. nach 6 Monaten ist die langsamer als die alte 80GB-5400er-Samsung-IDE-Laufwerk was noch drinsteckt .. soviel zum Thema Trim / GB wird völlig überbewertet.
 
Und man kann nicht SSD mit SSD direkt vergleichen. Die eine hat ne gute GC und kann fehlendes Trim kompensieren, die andere halt nicht. Die eine hat X GB feste Reserve, die andere nicht. Ich beende die Diskussion fuer mich einfach damit: Meine SSD ist x mal vollgeschrieben. Trotz fehlendem Trim auf 2/3 des Platzes habe ich die gleiche Performance wie vor den >1000 Betriebsstunden der SSD. Vielleicht habe ich einfach eine gute SSD fuer mein Szenario gefunden.
 
IronEagle schrieb:
Erst wenn er komplett beschrieben wurde. Nur durch das Anlegen von Partition, LVM und dmcrypt-Gedoens wirkt der fuer die SSD nicht voll, im Gegenteil :)
Zum Vergrößern anklicken....

Soweit ich weiß sieht ein DM-Crypt Device auf und für den Datenträger immer voll beschrieben aus, damit keine Relation zwischen verschl. Daten und freiem Speicher existiert. Deswegen wird trim bei DM-Crypt auch nur absolut Optional sein, wenn es überhaupt kommt, weil es eben eine Lücke ist. Sprich du legst ein 20 GB Dm Crypt Device an = die SSD denkt es sind 20 GB belegt. Wieviel davon frei ist oder nicht, ist egal.

Edit: IronEagle warf grad den Einwand per PN ein, dass es ja relativ lang dauern würde das dm-crypt device anzulegen. Ich weiß nicht mehr wielange es dauert, aber das stimmt schon irgendwie - keine Ahnung was nun richtig ist ;)

Für /usr/bin usw. spricht übrigens Manipulationssicherheit, falls jemand Argumente braucht :D
 
Zuletzt bearbeitet:
da smit dem problem des trims bei trucrypt-containern versteh ich jetzt nicht.

im container?
das wäre ja auch quark, denn das ist ja eine datei für die ssd... dann wärs verschmerzbar, zumal die datenblöcke ja eh von der ssd beim umschreiben gern neu verteilt werden, so das die zelle in der das alte lag oft wieder frei ist nachdem es geändert wurde...

sogesehen wird auch die containerdatei irgendwann getrimmt ;)
 
[W2k]Shadow schrieb:
da smit dem problem des trims bei trucrypt-containern versteh ich jetzt nicht.

im container?
das wäre ja auch quark, denn das ist ja eine datei für die ssd... dann wärs verschmerzbar, zumal die datenblöcke ja eh von der ssd beim umschreiben gern neu verteilt werden, so das die zelle in der das alte lag oft wieder frei ist nachdem es geändert wurde...

sogesehen wird auch die containerdatei irgendwann getrimmt ;)
Zum Vergrößern anklicken....

Es gibt ja 2 Arten von TC Containern: 1. den dynamisch wachsenden, 2. den statischen

1): Wächst nur, kann nicht schrumpfen -> keine Relation zwischen Daten <-> freiem Platz im Container
2): Belegt immer den Speicher entspr. seiner Größe -> keine Relation zwischen Daten <-> freiem Platz im Container

Würdest du jetzt Trim einführen, wäre plötzlich genau erkennbar (zumindest theoretisch) wieviel % des Containers belegt und wieviel frei sind. Das würde u.U. zu Abhängigkeiten führen, welche dich den Schlüssel berechnen lassen könnten.

Genauer kann ich es dir leider so aus dem Stehgreif auch nicht erklären :)
 
nein wäre es in beiden fällen nicht, denn:
wenn der container sich ändert, werden die geänderten daten geschrieben.. diese daten sidn abe rin blöcke geteilt, udn die ssd selbst ist nru halt beim neu schreiben des blocks dann de rmeinung, dass dieser block jetzt in ne andere zelle kommt...
das ist sogesehen also schon trim in der ssd...
dabei dürfte es unerheblich sein, ob das volumen mit wächst oder nicht
 
[W2k]Shadow schrieb:
wenn der container sich ändert, werden die geänderten daten geschrieben.. diese daten sidn abe rin blöcke geteilt, udn die ssd selbst ist nru halt beim neu schreiben des blocks dann de rmeinung, dass dieser block jetzt in ne andere zelle kommt...
das ist sogesehen also schon trim in der ssd...
Zum Vergrößern anklicken....

Das Problem ist, dass der alte Block aber "beschrieben" bleibt und wenn er wieder belegt wird erst gelöscht werden muss.
Trim sorgt dafür, dass die SSD ihn "direkt" löscht (bzw. es gibt auch Trimskripte, dann von Zeit zu Zeit), dann wird er explizit als gelöscht markiert und kann nächstes Mal direkt geschrieben werden. Das ist also kein "Trim in der SSD".

Kann man unter Linux übrigens sehr schön nachvollziehen (und damit auch testen ob Trim geht).

Also ich stell mir das so vor:

Ohne Trim: 8 Gbyte Daten die quer verteilt über die Sektoren sind, aber irgendwo steht ja was wozu gehört, da aber alle Sektoren der bla.tc belegt sind, weiß man nicht was frei ist und was nicht.

Mit Trim (sofern es das Gäbe): Ebenfalls quer verteilt, aber es fehlen genug Sektoren um damit den Container komplett darzustellen (oder werden 0en explizit zugeordnet?), somit weiß man dass der Container nur % groß ist oder gar wo diese "Lücken" sind.

Die Erklärung inwiefern das kryptographisch/mathematisch eine Schwäche darstellt, muss ich dir leider schuldig bleiben (weil ich es selbst nicht weiß) ;)
 
Zuletzt bearbeitet:
da smein ich doch.. udn ja trim kann die zelle nur mit leerem inhalt füllen ist mri klar, ne leere zelel gibts nru bei herstellung ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben