/dev/mapper/dm_crypt-0以下をサポートするLUKSデバイスです/dev/sdc3。
$ sudo pv /dev/sdc3 >/dev/null
[ 503MiB/s]
$ sudo pv /dev/mapper/dm_crypt-0 >/dev/null
[72.0MiB/s]
したがって、暗号化されたデバイスはrawデバイスよりはるかに遅くなります。なぜ？
top説明する：
top - 20:07:52 up 9 min, 2 users, load average: 2.03, 1.42, 0.83
Tasks: 604 total, 3 running, 601 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 3.6 sy, 0.0 ni, 96.1 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st
GiB Mem : 472.4 total, 397.7 free, 0.9 used, 73.8 buff/cache
GiB Swap: 8.0 total, 8.0 free, 0.0 used. 469.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4845 root 20 0 0 0 0 R 81.2 0.0 0:21.96 kworker/u101:2+kcryptd/253:0
4846 root 20 0 0 0 0 R 81.2 0.0 0:16.22 kworker/u101:4+kcryptd/253:0
4844 root 20 0 5640 2200 1960 D 13.8 0.0 0:08.04 pv
4725 tange 20 0 9912 4624 3220 R 1.0 0.0 0:06.55 top
したがって、これは2回の復号化によるものかもしれませんkcryptd。システムには48個のコアがあります。
パフォーマンスがこの2つに制限されている場合は、kcryptd作業を完了して500 MB / sを得るために48コアをどのように使用できますか？
私はこれをテストし、それがシングルスレッドの問題かもしれないと思いました。
parallel --recend '' --pipepart -a /dev/mapper/dm_crypt-0 --block -1 'cat >/dev/null'
kcryptdで指定されているように、これはより多くの機能を有効にし、完全な500 MB / sを提供しますtop。 LUKSという意味だからいいですできる500MB/sの速度を提供します。
順次書き込みも良いです（500 MB / sではありませんが、約300 MB / s - SSD速度のために制限される可能性があります）。
したがって、問題はシーケンシャル読み取りに限定されているようです。
$ cat /proc/cpuinfo
processor : 47
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6174
stepping : 1
microcode : 0x10000d9
cpu MHz : 2200.035
cache size : 512 KB
physical id : 1
siblings : 12
core id : 5
cpu cores : 12
apicid : 27
initial apicid : 27
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
bogomips : 4400.20
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
$ sudo cryptsetup luksDump /dev/sdc3
LUKS header information
Version: 2
Epoch: 18
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 9498ddbe-9613-4ae3-8fb4-e65913d800c8
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
$ sudo cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 260580 iterations per second for 256-bit key
PBKDF2-sha256 717220 iterations per second for 256-bit key
PBKDF2-sha512 565574 iterations per second for 256-bit key
PBKDF2-ripemd160 403919 iterations per second for 256-bit key
PBKDF2-whirlpool 262669 iterations per second for 256-bit key
argon2i 4 iterations, 256407 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 260616 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 74.8 MiB/s 130.1 MiB/s
serpent-cbc 128b 47.6 MiB/s 144.4 MiB/s
twofish-cbc 128b 116.1 MiB/s 137.4 MiB/s
aes-cbc 256b 33.5 MiB/s 68.5 MiB/s
serpent-cbc 256b 53.4 MiB/s 144.3 MiB/s
twofish-cbc 256b 125.7 MiB/s 150.8 MiB/s
aes-xts 256b 130.3 MiB/s 132.6 MiB/s
serpent-xts 256b 119.3 MiB/s 138.9 MiB/s
twofish-xts 256b 135.4 MiB/s 144.2 MiB/s
aes-xts 512b 99.0 MiB/s 102.7 MiB/s
serpent-xts 512b 136.8 MiB/s 138.9 MiB/s
twofish-xts 512b 144.9 MiB/s 144.3 MiB/s