Proxmox 호스트에서 모든 명령을 실행했고 디스크를 LUKS 암호화했을 때 읽기 속도가 28%, 쓰기 속도가 66% 증가했습니다. aes-ni가 활성화되어 있고 하드웨어 가속을 통해 충분한 성능을 얻을 수 있을 것이므로 실제로 무슨 일이 일어나고 있는지 알 수 없습니다... 또한 암호화되지 않은 드라이브에 더 빨리 쓰는 것은 의미가 없습니다.
root@red:/dev/mapper# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 1007K 0 part
├─sda2 8:2 0 512M 0 part
└─sda3 8:3 0 111.3G 0 part
sdb 8:16 0 111.8G 0 disk
├─sdb1 8:17 0 1007K 0 part
├─sdb2 8:18 0 512M 0 part
└─sdb3 8:19 0 111.3G 0 part
sdc 8:32 0 12.8T 0 disk
sdd 8:48 0 12.8T 0 disk
nvme0n1 259:0 0 465.8G 0 disk
root@red:/dev/mapper# hdparm -t /dev/nvme0n1
/dev/nvme0n1:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Timing buffered disk reads: 4774 MB in 3.00 seconds = 1591.14 MB/sec
root@red:/dev/mapper# dd if=/dev/zero of=/dev/nvme0n1 oflag=direct bs=128k count=32k
32768+0 records in
32768+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.39636 s, 1.8 GB/s
그런 다음 다음과 같이 암호화하고 싶습니다.
root@red:~# cryptsetup luksFormat /dev/nvme0n1
WARNING!
========
This will overwrite data on /dev/nvme0n1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/nvme0n1:
Verify passphrase:
root@red:~# cryptsetup luksOpen /dev/nvme0n1 Test
Enter passphrase for /dev/nvme0n1:
root@red:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 1007K 0 part
├─sda2 8:2 0 512M 0 part
└─sda3 8:3 0 111.3G 0 part
sdb 8:16 0 111.8G 0 disk
├─sdb1 8:17 0 1007K 0 part
├─sdb2 8:18 0 512M 0 part
└─sdb3 8:19 0 111.3G 0 part
sdc 8:32 0 12.8T 0 disk
sdd 8:48 0 12.8T 0 disk
nvme0n1 259:0 0 465.8G 0 disk
└─Test 253:0 0 465.8G 0 crypt
root@red:~# hdparm -t /dev/mapper/Test
/dev/mapper/Test:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Timing buffered disk reads: 3450 MB in 3.00 seconds = 1149.84 MB/sec
root@red:~# dd if=/dev/zero of=/dev/mapper/Test oflag=direct bs=128k count=32k
32768+0 records in
32768+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 6.83405 s, 628 MB/s
root@red:~#
이것은 cryptsetup의 벤치마크입니다.
root@red:~# cryptsetup benchmark
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1011.6 MiB/s 3031.2 MiB/s
serpent-cbc 128b 85.2 MiB/s 646.1 MiB/s
twofish-cbc 128b 192.3 MiB/s 354.1 MiB/s
aes-cbc 256b 792.4 MiB/s 2475.1 MiB/s
serpent-cbc 256b 87.2 MiB/s 648.4 MiB/s
twofish-cbc 256b 193.2 MiB/s 355.4 MiB/s
aes-xts 256b 1921.2 MiB/s 1919.5 MiB/s
serpent-xts 256b 626.2 MiB/s 634.2 MiB/s
twofish-xts 256b 349.9 MiB/s 353.1 MiB/s
aes-xts 512b 1780.3 MiB/s 1768.5 MiB/s
serpent-xts 512b 614.3 MiB/s 637.7 MiB/s
twofish-xts 512b 353.2 MiB/s 352.5 MiB/s
root@red:~# root@red:~# cryptsetup luksDump /dev/nvme0n1
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: XXXX
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]
root@red:~# sort -u /proc/crypto | grep module
module : aesni_intel
module : crc32_pclmul
module : crct10dif_pclmul
module : cryptd
module : ghash_clmulni_intel
module : kernel
module : serpent_avx2
module : serpent_avx_x86_64
module : serpent_generic
module : serpent_sse2_x86_64
module : twofish_avx_x86_64
module : twofish_generic
module : twofish_x86_64
module : twofish_x86_64_3way
root@red:~#
aes-xts를 사용한 벤치마크에서 약 1700MB/s가 나오는데 왜 드라이브 속도가 그렇게 많이 영향을 받는지 궁금합니다. 어떤 도움이라도 대단히 감사하겠습니다!
답변1
~에서cryptsetup 벤치마크매뉴얼 페이지:
참고: 이 벤치마크는 메모리만 사용하며 참조용으로만 사용됩니다. 이것으로는 실제 스토리지 암호화 속도를 직접 예측할 수 없습니다.
출력의 첫 번째 줄도 이에 대한 힌트를 제공합니다 cryptsetup benchmark(강조):
root@archiso ~ # cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PBKDF2-sha1 1875806 iterations per second for 256-bit key
...
이것이 바로 실제 스토리지 계층에서 이러한 차이를 볼 수 있는 이유입니다 dd. 파일 시스템 유형과 마운트 옵션 자체가 자체 오버헤드를 추가합니다.예를 들어zstd 레벨 1 소프트 압축을 사용하는 Btrfs에서:
root@archiso ~ # hdparm -t /dev/nvme0n1
/dev/nvme0n1:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Timing buffered disk reads: 4658 MB in 3.00 seconds = 1552.45 MB/sec
# cryptsetup luksFormat /dev/nvme0n1p2
# cryptsetup open --allow-discards !$ luks
# hdparm -t /dev/mapper/luks
/dev/mapper/luks:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Timing buffered disk reads: 3638 MB in 3.00 seconds = 1212.52 MB/sec
# mkfs.btrfs --label btrfs -m dup --csum xxhash /dev/mapper/luks
# mount -t btrfs -o noatime,ssd,compress=zstd:1,autodefrag /dev/disk/by-label/btrfs /mnt
# dd if=/dev/zero of=/mnt/test oflag=direct bs=128k count=32k
32768+0 records in
32768+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 7.76791 s, 553 MB/s
압축하지 않으면 귀하와 비슷한 결과를 얻습니다.
# rm /mnt/test
# umount /mnt
# mount -t btrfs -o noatime,ssd,autodefrag /dev/disk/by-label/btrfs /mnt
# dd if=/dev/zero of=/mnt/test oflag=direct bs=128k count=32k
32768+0 records in
32768+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 6.35182 s, 676 MB/s
이는 Intel 코어 i5-10210U 프로세서와 2x4G LPDDR3 2133 MT/s Samsung 메모리를 갖춘 Intel 660p 512G NVMe 드라이브에 있습니다. 소프트웨어 암호화의 이점을 누리기 위해서는 NVMe 스토리지의 성능을 너무 많이 포기해야 한다는 점은 정말 안타깝습니다.
Cloudflare는 몇 가지 작업을 수행했습니다.Linux 디스크 암호화 가속화어느Linux 5.9에 병합그리고일반적으로 5.10.9에서 사용 가능, 하지만 있습니다보고서실제로는손상 성능저장이 포함되면 내 사용 사례에서 이를 확인할 수 있습니다.
소프트웨어가 최신이라고 가정하면 다음을 사용할 수 있습니다.cryptsetup open그리고:
--perf-no_read_workqueue,--perf-no_write_workqueuedm-crypt 내부 작업 대기열을 우회하고 읽기 또는 쓰기 요청을 동기식으로 처리합니다.
노트:이러한 옵션은 낮은 수준의 dm-crypt 성능 조정에만 사용되며 기본 dm-crypt 동작을 변경해야 하는 경우에만 사용해야 합니다. 커널 5.9 이상이 필요합니다.
위의 Reddit 링크에서는 읽기 옵션을 활성화하고 쓰기 옵션을 무시할 것을 권장합니다. 언제나 그렇듯, 테스트하고 벤치마킹해야 합니다!