LUKS 암호화를 사용하는 XFS가 왜 그렇게 느린가요(Samsung 980 PRO SSD)

LUKS 암호화를 사용하는 XFS가 왜 그렇게 느린가요(Samsung 980 PRO SSD)

기본 설정을 사용하여 XFS 파일 시스템에서 LUKS/dm-crypt 암호화의 오버헤드를 측정하려고 했습니다. 삼성 980 PRO SSD(NVME 종류)를 탑재한 노트북에서 git status거대한 트리(크로미엄 체크아웃)의 오버헤드가 원래 파티션에 비해 15~20% 느린 것으로 나타났으며 , tar xf해당 트리로 확장하는 오버헤드는 25-25% 느려집니다. 30%. ext4의 경우 속도 저하가 git status8%와 20%이고, btrfs의 경우 속도 저하가 10%와 17%입니다. 이는 Fedora 및 5.14.10 커널에 있습니다.

Cloudflare 블로그이제 암호화 성능을 조정하는 데 사용할 수 있는 2개의 새로운 옵션(--perf-no_read_workqueue, cryptsetup의 경우 --perf-no_write_workqueue)을 언급했지만 제 경우에는 속도가 느려졌습니다. 어떤 경우에도 XFS와 다른 파일 시스템 간의 차이점을 설명하지 않습니다. 그렇다면 XFS가 특히 LUKS 오버헤드에 취약한 이유는 무엇일까요?

답변1

이 문제는 기본적으로 512바이트 섹터를 사용하는 Fedora의 LUKS 설정으로 인해 발생한 것으로 나타났습니다. 제안대로 4K로 늘리세요레딧--perf-no_read_workqueue 옵션을 사용하면 cryptsetup open --type=luksXFS의 LUKS 암호화 오버헤드를 7-9%로 줄이는 데 충분합니다.

512의 이유는 Samsung 980 PRO가 기본적으로 이 값을 보고하고 Fedora 35가 이와 일치하기 때문입니다.

관련 정보