Problem:
Wenn ich viel auf verschlüsselte Partitionen schreibe, bekomme ich nicht eine Verlangsamung, sondern kann eigentlich nichts machen.
Um das Problem zu erläutern, erst einmal mein Versuchsaufbau. (/tmp ist tmpfs und liegt vollkommen im Arbeitsspeicher)
Code: Alles auswählen
dd if=/dev/zero of=/tmp/img bs=1024k count=4000
losetup /dev/loop5 /tmp/img -e aes -k 128
mkfs.xfs /dev/loop5
mount /dev/loop5 /mnt
date ; dd if=/dev/zero of=/mnt/testfile bs=1024k count=3900 ; sync ; date
umount /mnt
losetup -d /dev/loop5
Zunächst einmal wird nur einer meiner vier Cores verwendet.
Nach einiger Zeit weigert sich mein Desktop (e17), Tastatur- und Mausclicks entgegenzunehmen. Bereits laufende Programme laufen aber weiter. Animationen wie vom CPU-Anzeiger, Mauszeiger und Cursorblinken laufen ebenfalls. Wenn diese Blockade endet, werden die verpassten Tastendrücke/Mausclicks auf einen Schlag nachgeholt.
In Extremfällen (z.B. sehr großen Dateien) frieren auch die Animationen ein. Laut LED liegt auch meine Platte brach. Irgendwann geht es aber weiter.
Diese Einfrierungen dauern in der Regel 30 Sekunden bis 1 Minute.
Diese Probleme waren übrigens früher besonders extrem, wenn ich auf langsame verschlüsselte Medien wie USB-Sticks geschrieben habe. Nach einigen Gigabytes konnte das langsam aber sicher zum kompletten Aufhängen des Rechners führen. Das habe ich aber in letzter Zeit nicht mehr getestet.
Ich habe aes und serpent getestet. Serpent ist erheblich schlimmer als aes was dieses Problem angeht.
Versuchte Abhilfe:
Ich habe erst vor kurzem erfahren, dass das Modul pcrypt existiert, das eine Parallelisierung der Verschlüsselung erlauben soll. Ich habe heute meinen Kernel auf den neuesten Stand gebracht (3.0.4) und dieses Modul gebaut und geladen.
Ergebnis: Bringt gar nichts, weder beim Schreiben noch beim Lesen. Gefühlt ähnlich langsam, es wird nie mehr als ein Core verwendet. Ich habe das Modul auch fest einkompiliert, das hat ebenfalls nichts gebracht.
Nebenbei:
Ich habe bemerkt, dass bei besonders schlimmen Kopieraktionen in dmesg Stacktraces auftauchen, vermutlich nach den Totaleinfrierungen. Ob das nur mit pcrypt auftrat oder nicht müsste ich noch austesten. Vermutlich war das nur der Watchdog.
Bei den Tests mit pcrypt habe ich durch wildes Umkopieren auch geschafft, den Rechner zum Absturz zu bringen. Momentan ist mir das etwas zu riskant, deshalb habe ich pcrypt wieder entfernt, auch wenn ich mir nicht sicher bin, ob pcrypt überhaupt dafür verantwortlich war. Morgen werde ich vielleicht die Möglichkeit haben über RS232 zu debuggen.
Frage:
Bin ich alleine mit dem Problem? Ich kann es kaum glauben, denn die Probleme sind doch massiv, und ich habe immer wieder große Umkopieraktionen, z.B. auf meine Backup-Festplatte.
Danke!