Truecrypt / HDD Performance

[DragonTEC]

Hallo,

ich bin grad über ein sehr eigentümliches Verhalten meines Rechners gestolpert und würde mich freuen wenn mir einer einen Tip geben kann warum er tut was er tut..

Generell benutz ich LVM auf einer per Truecrypt verschlüsselten Partition. Was mich stutzig gemacht hat ist, das ich auf dem Truecrypt Volume nur etwa 50% des Write-Speeds habe den ich sonst auf der Platte habe.. Das Truecrypt einen gewissen performanceverlust hat ist mir klar, aber bei einem 1090T (6x3,2GHz) und 16GB Ram sollte der deutlich moderater ausfallen. Deshalb hab ich angefangen Geschwindigkeitstests zu machen:

ext4 auf einer LVM Partition auf einer Truecrypt Partition: 55MB/s
nur ext4 auf einer Partition: 110MB/s
nur lvm2 auf einer Partition: 110MB/s
ext4 auf einer Truecrypt Partition: 53MB/s

Werte sind immer Mittel aus mehreren läufen. Zum Testen habe ich 'dd if=/dev/zero of=image.img bs=2M count=500' verwendet. Die Platte war eine WD20EADS.

Soweit so gut, war recht konsisten und Truecrypt war halt einfach um die Hälfe langsamer. Als Gegenprobe habe ich das gleiche dann aber auf einer alten WD5000AAKS versucht, die ich noch rumliegen hatte:

ext4 on lvm on truecrypt: 88MB/s bei 1,3s CPU-Zeit
ext4: 89MB/s bei 2,4s CPU-Zeit
ext3 on lvm: 89MB/s bei 2,4s CPU-Zeit
ext4 on truecrypt: 88MB/s bei 1,3s CPU-Zeit

Kommando war diesmal 'time( dd if=/dev/zero of=image.img bs=2M count=500 )'. CPU-Zeit bei der anderen Platte hab ich im nachhinein auch noch mal getestet: auch ca. 1,3s CPU zeit bei ext4 on lvm on truecrypt.

Dies hat mich nun sehr überrascht, da bei gleichem Setup die andere Platte mehr oder weniger gar nicht von einem Truecrypt-Performanceverlust betroffen ist, aber gleichzeitig die erforderliche CPU-Leistung beim schreiben ohne Truecrypt fast doppelt so groß ist wie beim schreiben mit truecrypt.

Kann mir das irgendwer erklären?

P.S. Cachen kann ich eigentlich ausschließen, da ich die einzelnen läufe immer nacheinander und in unterschiedlicher Reihenfolge gemacht habe. Sollte ien Cachen stattgefunden haben, so hätte dies für alle passieren müssen.

Nachtrag:

Ich hab jetzt auch mal Read-Performance getestet und es wird nur noch seltsamer:

ext4 on lvm on truetrypt: 200MB/s (!!!) bei 4s CpU-Zeit (ja, der zieht wirklcih 1GB in 5 sek. durch)
ext4: 84MB/s bei 5,5s CPU
ext4 on lvm: 80MB/s bei 6s CPU
ext4 on truecrypt: 75MB/s bei 4s CPU

Kommando war hier 'time( dd if=image.img of=/dev/null )

Erst dachte ich ich hab das Problem entdeckt und truecrypt cached einfach doch noch irgendwo, aber das es an truecrypt liegt hat sich dann mit dem 4. Test zerschlagen, der normale Ergebnisse liefert.

Ach kann ich das nur wieder bei der 500GB Platte beobachten, die 2TB Platte hat normale werte: ext4 on lvm on truecrypt: 69MB/s bei 3,9s CPU

 

[Dragonix]

Auch wenn dir die Antwort kaum hilft: Gibt's einen Grund, warum du TrueCrypt einsetzt? Ich glaube, TrueCrypt verwendet/ist mit Fuse implementiert, das kann glaube ich Performance kosten (ob's allerdings in dieser Dimension sein darf - keine Ahnung...)

Grüße
Matthias

 

[DragonTEC]

Ach, das is historisch gewachsen.. hätte ich jetzt nicht so wiedersprüchliche ergebnisse gekriegt hätte ich durchgetestet ob dm-crypt / LURKS schneller sind und das genommen was besser performt.. Allerdings frag ich mich jetzt vorallem:

a) Warum sich die Truecrypt performance so drastisch zwischen 2 Platten unterscheidet (Alle Tests wurden auf 100GB Partitionen gemacht, an der Größe kanns also nich liegen)
b) Warum schreiben mit truecrypt weniger CPU kostet als ohne

P.S.: Fuse is bei mir fest in den Kernel kompiliert, daran sollte es nich liegen..

 

[Astorek86]

P.S.: Fuse is bei mir fest in den Kernel kompiliert, daran sollte es nich liegen..

Hat nichts damit zu tun; die ganzen Zugriffe über FUSE muss trotzdem vom Linuxkernel extra verarbeitet werden - da ist ein gewaltiger Overhead drauf, damit eben Drittprogramme wie TrueCrypt mit ihren eigenen Dateisystemen innerhalb des Linuxkernels umgehen können, ohne dass der Kernel neucompiliert werden muss. Es werden zig Informationen über das Dateisystem von Userspace zu Kernelebene und umgekehrt übertragen. ALLES, was über FUSE geregelt wird, ist zwangsläufig langsamer...

Das Verhalten kann ich mir allerdings auch nicht erklären. Ich vermute, das hat irgendwie mit einem Zusammenspiel aus LVM, FUSE und Truecrypt zu tun, kann aber ebenfalls nicht erklären, wieso... Es könnte auch am internen Festplattencache liegen, der bei der einen Platte zufällig besser skaliert als auf der anderen... Liefen die Tests unter exakt gleichen Bedingungen durch? (Distribution, Kernel-/Truecrypt-/FUSE-Version, Dateisystem immer gleich gemountet etc.)