|
Reinsn
Anmeldungsdatum:
3. Mai 2010
Beiträge: Zähle...
|
Hallo, ich habe ein sehr seltsames Performance-Problem beim Zusammenspiel eines mdadm-RAID5s mit dm-crypt: Ausgangsbasis ist ein RAID5 (3x2TB) als /dev/md0 Folgende Performancedaten: /dev/md0 direkt als ext4-Partition formatiert: root@chimera:/mnt/test# time sh -c "dd if=/dev/zero of=/mnt/test/testfile bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 97,4915 s, 168 MB/s
real 1m38.526s
user 0m0.256s
sys 0m15.809s /dev/md0 mit LVM (ext4-Partition auf LV): root@chimera:~# time sh -c "dd if=/dev/zero of=/mnt/test/testfile bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 102,549 s, 160 MB/s
real 1m52.440s
user 0m0.416s
sys 0m14.889s /dev/md0 mittels cryptsetup eingerichtet (aes-xts-plain 256): root@chimera:~# time sh -c "dd if=/dev/zero of=/mnt/test/testfile bs=8k count=2000000 && sync"
^C1766383+0 Datensätze ein
1766383+0 Datensätze aus
14470209536 Bytes (14 GB) kopiert, 581,671 s, 24,9 MB/s
real 9m41.701s
user 0m0.320s
sys 0m11.417s Hier ein Prozess-Abbild während des Schreibens: top - 22:57:38 up 16:42, 2 users, load average: 7.17, 5.19, 3.67
Tasks: 121 total, 1 running, 120 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 3.2%sy, 0.0%ni, 59.3%id, 37.4%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 8087012k total, 7915984k used, 171028k free, 2928k buffers
Swap: 8298492k total, 0k used, 8298492k free, 7480828k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9360 root 20 0 0 0 0 D 4 0.0 1:20.97 kworker/0:2
10163 root 20 0 0 0 0 D 4 0.0 1:24.28 kworker/1:2
10976 root 20 0 0 0 0 D 4 0.0 0:11.59 kworker/2:1
6089 root 20 0 0 0 0 S 3 0.0 71:46.42 md0_raid5
11211 root 20 0 12912 664 544 D 3 0.0 0:08.75 dd
9745 root 20 0 0 0 0 S 2 0.0 0:22.31 kworker/3:1
35 root 20 0 0 0 0 S 1 0.0 0:13.28 kswapd0
11416 root 20 0 17332 1288 956 R 0 0.0 0:00.02 top
1 root 20 0 24324 1460 500 S 0 0.0 0:00.84 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.68 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.12 watchdog/0
8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
10 root 20 0 0 0 0 S 0 0.0 0:00.35 ksoftirqd/1
12 root RT 0 0 0 0 S 0 0.0 0:00.11 watchdog/1
13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2Wie Ihr seht bricht bei der Verwendung von dm-crypt auf dem RAID die Performance extrem stark ein. Die CPU ist zwar nur ein i3-3220T, aber hat ja laut "top" nichts zu tun. Die Load des Servers steigt auf 7-8. Ich habe bereits verschiedene Verschlüsselungstechniken und --align-payload Parameter von LUKS/dm-crypt ausprobiert, jedoch ohne Erfolg. Auch das Testweise anlegen eines verschlüsselten Logical Volume innerhalb des LVM bringt das gleiche Ergebnis. Genausowenig Abhilfe schafft eine schwächere Verschlüsselung. Kann sich das irgendjemand erklären??? Hier noch weitere Infos zum System: Ubuntu 12.04 x86_64 Server
Kernel: 3.2.0-31-generic CPU: i3-3220T
Board: MSI Z77MA-G45
8GB RAM
3x Western Digital WD20EARX Scheinbar bin ich mit dem Problem auch nicht alleine, nur Lösungen gibt es keine: http://dominik.honnef.co/posts/2011/10/linux_raid___dm_crypt__poor_write_performance/ http://www.saout.de/pipermail/dm-crypt/2012-February/002342.html http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5683
|
|
frostschutz
Anmeldungsdatum:
18. November 2010
Beiträge: 7777
|
Stimmt das Align? Wie sind die Platten partitioniert? parted /dev/sda unit s print, mdadm -E /dev/sda1, gleiches für /dev/sdb, cat /proc/mdstat, cryptsetup luksDump /dev/md1 (Payload offset), ...? Die CPU hat kein AES-NI, Geschwindigkeitsrekorde kannst schon allein daher nicht erwarten.
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Die Platten sind aligned (Array=sdb,sdc,sdd root@chimera:~# parted /dev/sdb unit s print
Modell: ATA WDC WD20EARX-00P (scsi)
Festplatte /dev/sdb: 3907029168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Nummer Anfang Ende Größe Dateisystem Name Flags
1 2048s 3907029134s 3907027087s Linux RAID RAID
sdc und sdd identisch. root@chimera:~# mdadm -E /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : edbaa10f:eefbe9a5:93060f6c:59d40d5a
Name : chimera:0 (local to host chimera)
Creation Time : Wed Sep 26 10:48:34 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906764943 (1862.89 GiB 2000.26 GB)
Array Size : 3906764544 (3725.78 GiB 4000.53 GB)
Used Dev Size : 3906764544 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1a910c47:7acd8ef0:06107914:8454ad21
Update Time : Wed Sep 26 18:34:28 2012
Checksum : aca96f47 - correct
Events : 16
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AAA ('A' == active, '.' == missing)Das RAID rebuilded allerdings gerade, vorher war chunk size=512. Payload des Tests gestern: root@chimera:~# cryptsetup luksDump /dev/datavg/testlv
LUKS header information for /dev/datavg/testlv
Version: 1
Cipher name: aes
Cipher mode: xts-plain
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 46 ea 2e 76 31 05 9b 95 de 43 7d 58 d9 5a 30 4c e3 d1 14 b6
MK salt: 20 6a 3c 2f 56 df 44 71 d2 f6 b4 8e 27 49 49 a4
20 5d 4c 43 c0 31 1d bd f4 f1 64 54 49 f8 f8 af
MK iterations: 48500
UUID: 0b1ecb5a-567a-404f-853d-91ddc385732f
Key Slot 0: ENABLED
Iterations: 194213
Salt: 92 e0 70 4f 73 9e 1a 35 aa 95 07 17 a8 e0 ba 5a
23 56 8c 15 c8 eb 18 47 e7 c8 4c b0 f3 12 27 45
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
|
|
frostschutz
Anmeldungsdatum:
18. November 2010
Beiträge: 7777
|
Align stimmt, Data Offset des RAIDs ist allerdings riesig (128MiB? Wozu?). cat /proc/crypto, was steht bei xts(aes) als Driver, aes oder aes-asm? Wie ist eig. die Performanz wenn du direkt auf ein Device schreibst statt in eine Testdatei?
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
RAID wurde neu mittels | mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 --chunk=64 /dev/sdb1 /dev/sdc1 /dev/sdd1
|
angelegt. Das Data Offset hat mdadm selbstständig gewählt. Bei /proc/crypto finde ich kein xts, bei aes steht aes-generic. root@chimera:~# cat /proc/crypto
name : cbc(aes)
driver : cbc(aes-generic)
module : kernel
priority : 100
refcnt : 5
selftest : passed
type : givcipher
async : no
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : eseqiv
name : cbc(aes)
driver : cbc(aes-generic)
module : kernel
priority : 100
refcnt : 5
selftest : passed
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
name : hmac(sha256)
driver : hmac(sha256-generic)
module : kernel
priority : 0
refcnt : 2
selftest : passed
type : shash
blocksize : 64
digestsize : 32
name : hmac(sha1)
driver : hmac(sha1-generic)
module : kernel
priority : 0
refcnt : 2
selftest : passed
type : shash
blocksize : 64
digestsize : 20
name : stdrng
driver : krng
module : kernel
priority : 200
refcnt : 2
selftest : passed
type : rng
seedsize : 0
name : crc32c
driver : crc32c-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
type : shash
blocksize : 1
digestsize : 4
name : aes
driver : aes-generic
module : kernel
priority : 100
refcnt : 9
selftest : passed
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
name : sha256
driver : sha256-generic
module : kernel
priority : 0
refcnt : 5
selftest : passed
type : shash
blocksize : 64
digestsize : 32
name : sha224
driver : sha224-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
type : shash
blocksize : 64
digestsize : 28
name : sha1
driver : sha1-generic
module : kernel
priority : 0
refcnt : 3
selftest : passed
type : shash
blocksize : 64
digestsize : 20
name : md5
driver : md5-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
type : shash
blocksize : 64
digestsize : 16
name : crc32c
driver : crc32c-intel
module : kernel
priority : 200
refcnt : 1
selftest : passed
type : shash
blocksize : 1
digestsize : 4 Welche Performanz auf Device? /dev/md0 oder direkt auf eine der Festplatten?
|
|
frostschutz
Anmeldungsdatum:
18. November 2010
Beiträge: 7777
|
Aufs verschlüsselte Device. Ist die Verschlüsselung denn nicht aktiv? Die Module werden möglicherweise erst bei Bedarf geladen, aber wenn du aes-xts einsetzt muss das xts auch im /proccrypto stehen. Und das sollte dann eig. aes-asm und nicht -generic sein... Kannst ja mal unter /lib/modules umschauen und das Modul ggf. von Hand laden. Bei mir ist das Zeug im Kernel fest eingebaut.
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Momentan ist dm-crypt nicht aktiv. Hab das RAID mit der 64k Chunk Size heute neu aufgebaut. Wenn es fertig ist teste ich nochmal die Performance direkt auf das verschlüsselte Device und poste den Output von /proc/crypto.
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
So, Sync des RAIDs ist fertig. Was schonmal erfreulich ist: Die Performance des /dev/md0 ohne dm-crypt ist mit der 64k Chunk-Size um 30MB gestiegen (ext4 direkt auf /dev/md0): root@chimera:~# time sh -c "dd if=/dev/zero of=/mnt/test/testfile bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 83,035 s, 197 MB/s
real 1m29.958s
user 0m0.412s
sys 0m15.061s Diesmal habe ich /dev/md0 direkt verschlüsselt per: cryptsetup -c aes-xts-plain -s 256 luksFormat /dev/md0 Kommt diesmal auf ~60MB/s root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/md0_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 271,431 s, 60,4 MB/s
real 4m31.558s
user 0m0.352s
sys 0m11.829s top: top - 20:53:42 up 14:06, 3 users, load average: 4.63, 2.62, 1.67
Tasks: 119 total, 2 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 20.6%sy, 0.0%ni, 59.9%id, 19.3%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8087012k total, 7873560k used, 213452k free, 7297544k buffers
Swap: 8298492k total, 0k used, 8298492k free, 99324k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5137 root 20 0 0 0 0 D 21 0.0 0:21.24 kworker/3:1
2126 root 20 0 0 0 0 R 21 0.0 0:34.29 kworker/1:2
5140 root 20 0 0 0 0 D 18 0.0 0:03.54 kworker/2:3
2912 root 20 0 0 0 0 D 17 0.0 0:55.45 kworker/0:1
2436 root 20 0 0 0 0 S 12 0.0 69:22.81 md0_raid5
5134 root 20 0 12912 664 544 D 4 0.0 0:09.65 dd
35 root 20 0 0 0 0 S 1 0.0 0:02.37 kswapd0
718 root 20 0 0 0 0 S 0 0.0 0:05.05 kworker/3:2
4585 root 20 0 0 0 0 S 0 0.0 0:48.45 kworker/2:2
5135 root 20 0 0 0 0 S 0 0.0 0:04.76 flush-252:0
5138 root 20 0 0 0 0 S 0 0.0 0:00.50 kworker/1:1
5339 root 20 0 17332 1292 960 R 0 0.0 0:00.02 top
1 root 20 0 24324 2300 1372 S 0 0.0 0:00.80 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.21 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.10 watchdog/0 Schonmal besser der Wert. Was mich allerdings stutzig macht. Mit viel schwächerer Verschlüsselung, nämlich: cryptsetup -c aes-cbc-benbi -s 128 luksFormat /dev/md0 Komme ich auf noch schlechtere Werte: root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/md0_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 296,351 s, 55,3 MB/s
real 4m56.401s
user 0m0.340s
sys 0m12.361s top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5503 root 20 0 0 0 0 D 30 0.0 0:32.49 kworker/1:0
5137 root 20 0 0 0 0 R 28 0.0 1:16.99 kworker/3:1
2912 root 20 0 0 0 0 D 24 0.0 1:46.91 kworker/0:1
4603 root 20 0 0 0 0 D 24 0.0 0:41.83 kworker/2:0
2436 root 20 0 0 0 0 S 16 0.0 69:57.07 md0_raid5
5501 root 20 0 12912 660 544 D 4 0.0 0:10.30 dd
35 root 20 0 0 0 0 S 2 0.0 0:03.72 kswapd0
1 root 20 0 24324 2300 1372 S 0 0.0 0:00.80 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.22 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.10 watchdog/0
8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
10 root 20 0 0 0 0 S 0 0.0 0:00.24 ksoftirqd/1
12 root RT 0 0 0 0 S 0 0.0 0:00.09 watchdog/1
13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2
15 root 20 0 0 0 0 S 0 0.0 0:00.11 ksoftirqd/2
16 root RT 0 0 0 0 S 0 0.0 0:00.08 watchdog/2
17 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3
19 root 20 0 0 0 0 S 0 0.0 0:00.09 ksoftirqd/3
20 root RT 0 0 0 0 S 0 0.0 0:00.08 watchdog/3
21 root 0 -20 0 0 0 S 0 0.0 0:00.00 cpuset
22 root 0 -20 0 0 0 S 0 0.0 0:00.00 khelper
23 root 20 0 0 0 0 S 0 0.0 0:00.00 kdevtmpfs
24 root 0 -20 0 0 0 S 0 0.0 0:00.00 netns
25 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/u:1 /proc/crypto: ...
name : xts(aes)
driver : xts(aes-generic)
module : kernel
priority : 100
refcnt : 1
selftest : passed
type : givcipher
async : no
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : eseqiv
name : xts(aes)
driver : xts(aes-generic)
module : xts
priority : 100
refcnt : 1
selftest : passed
type : blkcipher
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
name : cbc(aes)
driver : cbc(aes-generic)
module : kernel
priority : 100
refcnt : 9
selftest : passed
type : givcipher
async : no
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : eseqiv
name : cbc(aes)
driver : cbc(aes-generic)
module : kernel
priority : 100
refcnt : 9
selftest : passed
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
...
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Mit "twofish-xts-plain -s 256" root@chimera:~# cryptsetup luksOpen /dev/md0 md0_crypt
Geben Sie den Passsatz für /dev/md0 ein:
root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/md0_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 255,059 s, 64,2 MB/s
real 4m15.113s
user 0m0.252s
sys 0m11.897s top top - 21:19:29 up 14:32, 3 users, load average: 4.11, 1.96, 1.68
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 30.0%sy, 0.0%ni, 51.4%id, 18.2%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 8087012k total, 7848716k used, 238296k free, 7289332k buffers
Swap: 8298492k total, 0k used, 8298492k free, 91368k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5137 root 20 0 0 0 0 D 33 0.0 1:47.60 kworker/3:1
5523 root 20 0 0 0 0 D 31 0.0 0:21.34 kworker/2:1
2912 root 20 0 0 0 0 D 22 0.0 2:43.36 kworker/0:1
2436 root 20 0 0 0 0 S 17 0.0 70:24.89 md0_raid5
5619 root 20 0 0 0 0 D 17 0.0 0:14.42 kworker/1:1
5647 root 20 0 12912 664 544 D 6 0.0 0:08.11 dd
5648 root 20 0 0 0 0 S 2 0.0 0:04.01 flush-252:0
35 root 20 0 0 0 0 S 1 0.0 0:04.60 kswapd0
4603 root 20 0 0 0 0 S 0 0.0 0:53.42 kworker/2:0
5583 root 20 0 0 0 0 S 0 0.0 0:00.50 kworker/0:0
5649 root 20 0 0 0 0 S 0 0.0 0:00.31 kworker/3:2
5651 root 20 0 17332 1296 960 R 0 0.0 0:00.08 top
1 root 20 0 24324 2300 1372 S 0 0.0 0:00.81 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.22 ksoftirqd/0
6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0 0.0 0:00.10 watchdog/0
|
|
frostschutz
Anmeldungsdatum:
18. November 2010
Beiträge: 7777
|
Mich wundert warum bei dir nicht aes-asm genutzt wird. Auf meiner Intel E8400 ist das der Fall...
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Hat dein Prozessor "aes" als Flag? (cat /proc/cpuinfo | grep aes). Mein i7 im Notebook hat es, der i3-3220T nicht.
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Interessant ist auch folgendes: Habe jetzt 3 Logical Volumes alle twofish-xts-plain -s 256 verschlüsselt und auf alle drei gleichzeitig ein dd gestartet. Die Load geht bis auf 10/11 aber die CPU ist bei weitem nicht ausgelastet, oder lese ich "top" falsch? top: top - 21:50:31 up 15:03, 5 users, load average: 10.86, 9.08, 5.41
Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 23.8%sy, 0.0%ni, 31.1%id, 44.7%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 8087012k total, 7897484k used, 189528k free, 7241112k buffers
Swap: 8298492k total, 0k used, 8298492k free, 93800k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6287 root 20 0 0 0 0 D 20 0.0 0:17.46 kworker/0:3
2436 root 20 0 0 0 0 S 13 0.0 71:46.92 md0_raid5
5137 root 20 0 0 0 0 D 11 0.0 2:37.45 kworker/3:1
6285 root 20 0 0 0 0 D 11 0.0 0:30.14 kworker/3:3
6280 root 20 0 0 0 0 D 10 0.0 0:28.48 kworker/2:2
5690 root 20 0 0 0 0 D 10 0.0 0:16.22 kworker/2:0
5619 root 20 0 0 0 0 D 8 0.0 0:53.81 kworker/1:1
6556 root 20 0 0 0 0 D 8 0.0 0:00.57 kworker/1:0
6293 root 20 0 0 0 0 D 7 0.0 0:33.00 kworker/1:3
6289 root 20 0 12912 660 544 D 2 0.0 0:08.75 dd
6278 root 20 0 12912 660 544 D 1 0.0 0:07.24 dd
6282 root 20 0 12912 664 544 D 1 0.0 0:09.68 dd
35 root 20 0 0 0 0 S 0 0.0 0:09.28 kswapd0
2912 root 20 0 0 0 0 S 0 0.0 3:09.91 kworker/0:1
6279 root 20 0 0 0 0 S 0 0.0 0:03.41 flush-252:7
1 root 20 0 24324 2300 1372 S 0 0.0 0:00.83 init root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/testlv1_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 890,718 s, 18,4 MB/s
real 14m50.742s
user 0m0.304s
sys 0m12.317s root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/testlv2_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 954,037 s, 17,2 MB/s
real 15m54.041s
user 0m0.280s
sys 0m12.101s root@chimera:~# time sh -c "dd if=/dev/zero of=/dev/mapper/testlv3_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 946,864 s, 17,3 MB/s
real 15m46.899s
user 0m0.636s
sys 0m12.113s
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
|
|
Reinsn
(Themenstarter)
Anmeldungsdatum:
3. Mai 2010
Beiträge: 14
|
Ubuntu 10.04 von Stick gebootet liefert folgende Performance: (cryptsetup -c aes-xts-plain -s 256 luksFormat /dev/md0) root@ubuntu:~# time sh -c "dd if=/dev/zero of=/dev/mapper/md0_crypt bs=8k count=2000000 && sync"
2000000+0 Datensätze ein
2000000+0 Datensätze aus
16384000000 Bytes (16 GB) kopiert, 178.911 s, 91.6 MB/s
real 2m59.269s
user 0m0.290s
sys 0m11.680s Das ist auch schon eher das was ich erwartet habe. @frostschutz: Hier wird auch aes-asm geladen
|
|
frostschutz
Anmeldungsdatum:
18. November 2010
Beiträge: 7777
|
Dann lade aes-asm doch mal von Hand (oder fehlt gar das Modul???) und schau was dann passiert. Muss vermutlich gemacht werden bevor cryptsetup den Container aufmacht (in proc crypto sollte es richtig drinstehen). In dem Bug-Report wird aes-asm nicht erwähnt, ist also ein anderes Problem (oder niemand ist drauf gekommen).
|