LUKS(Universal dm-crypt) 쓰기 성능이 좋지 않음

암호화된 블록 장치가거대한성능 손실글쓰기그것에. 몇 시간 동안 웹을 읽고 실험해도 해결책은커녕 적절한 이해도 얻지 못했습니다.

간단히 말해서:btrfs를 블록 장치에 넣으면 매우 빠른 쓰기 속도(~170MB/s)를 얻을 수 있지만 파일 시스템과 블록(~20MB/s) 장치 사이에 dm-crypt/LUKS를 넣으면 왜 급락합니까? 시스템이 충분히 높은 암호화 처리량을 유지하기에 충분합니까?

상상하다

/home/schlimmchen/random/dev/urandom초기 데이터 가 담긴 4.0GB 파일입니다 .

dd if=/dev/urandom of=/home/schlimmchen/Documents/random bs=1M count=4096

읽기 속도가 매우 빠릅니다.

$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 6.58036 s, 648 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 0.786102 s, 5.4 GB/s

(두 번째로 캐시에서 파일을 읽은 것 같습니다.)

암호화되지 않은 btrfs

장치는 btrfs로 직접 포맷됩니다(블록 장치에는 파티션 테이블이 없습니다).

$ sudo mkfs.btrfs /dev/sdf
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt

최대 170MB/s의 쓰기 속도:

$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.1564 s, 157 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 25.1882 s, 169 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test3 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 29.8419 s, 143 MB/s

읽기 속도는 200MB/s를 훨씬 상회합니다.

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8265 s, 215 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.9821 s, 213 MB/s
$ dd if=/mnt/dd-test3 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8561 s, 215 MB/s

블록 장치의 암호화된 btrfs

LUKS를 사용하여 장치를 포맷하고 btrfs를 사용하여 결과 장치를 포맷합니다.

$ sudo cryptsetup luksFormat /dev/sdf
$ sudo cryptsetup luksOpen /dev/sdf crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt
$ sudo chmod 777 /mnt
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 210.42 s, 20.3 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M 
4265841146 bytes (4.3 GB) copied, 207.402 s, 20.6 MB/s

읽기 속도는 약간만 영향을 받습니다(이유는 무엇입니까?).

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.2002 s, 192 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.0794 s, 193 MB/s

루크스 덤프:http://pastebin.com/i9VYRR0p

블록 장치의 btrfs에 있는 파일의 암호화된 btrfs

암호화된 파일을 쓸 때 쓰기 속도는 150MB/s 이상으로 "급증"했습니다. 블록 장치에 btrfs를 넣고 16GB 파일을 할당한 다음 lukfsFormat편집하고 마운트했습니다.

$ sudo mkfs.btrfs /dev/sdf -f
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt
$ dd if=/dev/zero of=/mnt/crypted-file bs=1M count=16384 conv=fsync
17179869184 bytes (17 GB) copied, 100.534 s, 171 MB/s
$ sudo cryptsetup luksFormat /mnt/crypted-file
$ sudo cryptsetup luksOpen /mnt/crypted-file crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /tmp/nested/
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 26.4524 s, 161 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.5601 s, 155 MB/s

왜 이렇게 쓰기 성능이 좋아지나요? 쓰기 속도를 향상시키기 위해 파일 시스템과 블록 장치를 특수하게 중첩하면 무엇을 얻을 수 있습니까?

설정

이 문제는 동일한 배포판과 커널을 실행하는 두 시스템에서 재현 가능합니다. 그러나 System2의 커널 3.19.0에서는 쓰기 속도가 느려지는 것도 관찰되었습니다.

• 장치: SanDisk Extreme 64GB USB3.0 USB 메모리 스틱
• 시스템 1: Intel NUC 5i5RYH, i5-5250U(Broadwell), 8GB RAM, Samsung 840 EVO 250GB SSD
• 시스템 2: Lenovo T440p, i5-4300M(Haswell), 16GB RAM, 삼성 850 PRO 256GB SSD
• 배포판/커널: Debian Jessie, 3.16.7
• 비밀번호 설정: 1.6.6
• /proc/crypto시스템 1의 경우:http://pastebin.com/QUSGMfiS
• cryptsetup benchmark시스템 1의 경우:http://pastebin.com/4RxzPFeT
• btrfs(-tools) 버전은 3.17입니다.
• lsblk -t /dev/sdf:http://pastebin.com/nv49tYWc

아이디어

• 정렬은아니요제가 아는 한 그 이유는. 스틱의 페이지 크기가 16KiB인 경우에도 cryptsetup 페이로드 시작은 2MiB로 정렬됩니다.
• --allow-discards(cryptsetup의 luksOpen)은 예상한 대로 도움이 되지 않습니다.
• 실험한 적은 없지만 USB3.0 어댑터를 통해 연결된 외장 하드 드라이브가 매우 유사하게 작동하는 것을 관찰했습니다.
• 제가 보기에는 시스템이 64KiB 블록을 쓰고 있는 것 같습니다. ㅏ시스템 트랩 스크립트나는 적어도 그것이 사실이라는 것을 보여 주려고 노력합니다. /sys/block/sdf/stat이 가설은 많은 수의 쓰기가 병합되기 때문에 뒷받침됩니다. 그래서 내 생각에는 너무 작은 블록을 쓰는 것이 원인이 아닌 것 같습니다.
• 블록 장치 대기열 스케줄러를 NOOP로 변경하지 못했습니다.
• LVM 볼륨에 암호화를 넣는 것은 도움이 되지 않습니다.