☰

dm-integrity를 ​​사용한 Cryptsetup - 이상한 벤치마크 결과

tag-icon • tag-icon luks cryptsetup device-mapper integrity
dm-integrity를 ​​사용한 Cryptsetup - 이상한 벤치마크 결과

저는 다양한 cryptsetup볼륨을 벤치마킹하고 있는데 Debian에서 예상치 못한 결과를 얻었습니다.

내가 사용한 전화번호는이 말대략적인 참고 사항입니다. 슬라이드 중 하나는 다양한 구성에 대한 벤치마크 결과를 보여줍니다.

cryptsetup에 대한 다양한 구성 벤치마크를 보여주는 슬라이드, 로그는 모든 구성에서 R/W 처리량을 약 40% 줄입니다.

내 설정이 동일하지 않고 모든 테스트를 가상 머신에서 실행하므로 결과가 정확히 동일할 것이라고 기대하지는 않지만 슬라이드에 있는 내용을 대략적으로 반영해야 한다고 생각합니다. 특히 인증된 무결성 모드의 성능은 약 35(AES-XTS, HMAC-SHA256) 인증되지 않은 제품(AES-XTS), 일기 완성도와 일기가 아닌 완성도의 경우 35%입니다.

하지만 Ubuntu Server 20.04 및 Debian 10.4와 유사한 결과는 다음과 같습니다.

LUKS2 container:
    Capacity    1056964608 B
    Read        26.5MB/s
    Write       8855kB/s

LUKS2 with hmac-sha256, no journal:
    Capacity    1040322560 B
    Read        19.0MB/s
    Write       6352kB/s

LUKS2 with hmac-sha256, journaled:
    Capacity    1040322560 B
    Read        18.9MB/s
    Write       6311kB/s

무결성을 활성화하면 성능이 약 30% 감소할 것으로 예상됩니다. 그러나 일기와 일기가 아닌 무결성의 차이는 미미합니다. 즉, 이것이 원래 벤치마크보다 훨씬 낫기 때문에 기쁠 것입니다. 하지만 저널이 실제로 제 역할을 하고 있는지 어떻게 알 수 있으며, 그렇다면 어떻게 옵트아웃할 수 있습니까?

이것은 내 cryptsetup형식 명령입니다.

cryptsetup luksFormat --type luks2 /dev/sdb --sector-size 4096
cryptsetup luksFormat --type luks2 /dev/sdb --sector-size 4096 --integrity hmac-sha256
cryptsetup luksFormat --type luks2 /dev/sdb --sector-size 4096 --integrity hmac-sha256 --integrity-no-journal

벤치마크 명령:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/mapper/sdb --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75

VM은 각각 Debian 또는 Ubuntu의 기본 설정을 사용하여 VirtualBox 6.1에서 구성되었습니다. 디스크는 1GB VDI이며 크기가 고정되어 있고 0으로 미리 채워져 있으며 호스트 버퍼링이 비활성화되어 있습니다. 기본 SSD는 4k 섹터를 사용하므로 --sector-size 4096.

흥미롭게도 기본 --integrity변형과 --integrity-no-journal변형 모두 sdb_dif로그가 포함된 중간 매핑 장치를 생성하고 두 sdb장치 모두 크기가 동일합니다.

$ sudo integritysetup status /dev/mapper/sdb_dif
/dev/mapper/sdb_dif is active and is in use.
  type:    INTEGRITY
  tag size: 32
  integrity: (none)
  device:  /dev/sdb
  sector size:  4096 bytes
  interleave sectors: 32768
  size:    2031880 sectors
  mode:    read/write
  failures: 0
  journal size: 8380416 bytes
  journal watermark: 50%
  journal commit time: 10000 ms

$ sudo blockdev --getsize64 /dev/mapper/sdb
1040322560

답변1

답변 요약:

cryptsetup format 소홀히 하다배너 --integrity-no-journal.

대신 옵션은 다음과 같습니다.

  • 매번 open항상 배달됩니다 --integrity-no-journal.
  • 처음 열 때(즉, 내부 장치를 파일 시스템으로 포맷하거나 내부 장치를 MD RAID에 추가하는 경우) --persistent --integrity-no-journal보존 --integrity-no-journal설정을 제공합니다. 그러면 open앞으로는 플래그가 필요 없게 될 것입니다. 이 옵션은 cryptsetupdirect를 사용하는 경우에만 적용되며 효과가 없습니다 integritysetup.
  • open장치가 편집 되었을 때 발생합니다 refresh --persistent --integrity-no-journal. 이 옵션은 cryptsetup직접 사용하는 경우에만 적용되며 효과가 없습니다 integritysetup.

이전 텍스트:

--integrity-no-journal에 로고를 제공 하셨나요 integritysetup open? dm-integrity그런 것 같아요아니요포맷할 때 슈퍼블록에 기존 로그를 저장합니다(아님).

나는 사용한다 integritysetup format /dev/sdb1 --no-wipe.

그런 다음 integritysetup open /dev/sdb1 int-sdb1및 를 사용하여 엽니다 sync; echo 1 > /proc/sys/vm/drop_caches; dd count=16384 bs=4096 if=/dev/zero of=/dev/mapper/int-sdb1. 이는 항상 2.1Mb/s에서 2.4Mb/s 사이의 결과를 제공합니다.

닫았다가를 사용하여 다시 열고 integritysetup open /dev/sdb1 int-sdb1 --integrity-no-journal동일한 dd명령을 실행했습니다. 이번에는 4.0Mb/s에서 7.0Mb/s로 속도가 향상되었는데, 이는 상당한 개선입니다. 큰 차이점은 아마도 플래시 변환 레이어 때문일 것입니다. 그것은 형편없는 일회용 저렴한 디스크입니다.

나는 그것을 다시 반복했다 integritysetup format /dev/sdb1 --no-wipe --integrity-no-journal. 다시 말하지만 중요한 것은 기부 여부입니다 --integrity-no-journal.open주문하다,아니요도착하다format주문하다.

따라서 이것은 불분명한 질문일 수 있습니다 integritysetup. 명령 --integrity-no=journal을 따르면 format.

관련 정보