Abysmal General dm-crypt（LUKS）書き込みパフォーマンス

ブロックデバイスを暗号化すると、書き込み時にパフォーマンスが大幅に低下する問題を調査しています。インターネットで何時間も読んだり実験したりしても、解決策は言うまでもなく、適切な理解が得られませんでした。

要するに、ブロックデバイスにbtrfsを入れると書き込み速度が完全に速くなる（〜170MB / s）のに、dm-crypt / LUKSを入れると書き込み速度が急落する（〜20MB / s）ファイルシステムとブロックデバイス。ただし、システムは十分に高い暗号化スループットを維持できますか？

シナリオ

/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

（2回目は、明らかにファイルはキャッシュから読み取られました）。

暗号化されていない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

luksDump：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

書き込みパフォーマンスがこのように向上するのはなぜですか？ファイルシステムとブロックデバイスのこの特定のネストは、高速書き込みを支援するために何を達成しますか？

セットアップ

この問題は、同じディストリビューションとカーネルを実行する2つのシステムで再現可能です。ただし、System2のカーネル3.19.0では書き込み速度が遅いことも確認しました。

• デバイス：SanDisk Extreme 64GB USB3.0 USB Stick
• システム1：Intel NUC 5i5RYH、i5-5250U（Broadwell）、8GB RAM、Samsung 840 EVO 250GB SSD
• System2：Lenovo T440p、i5-4300M（Haswell）、16GB RAM、Samsung 850 PRO 256GB SSD
• ディストリビューション/カーネル：Debian Jessie、3.16.7
• cryptsetup：1.6.6
• /proc/cryptoSystem1の場合：http ://pastebin.com/QUSGMfiS
• cryptsetup benchmarkSystem1の場合：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ボリュームに暗号を入れることは役に立ちませんでした。

答え（私が知っているように）：並行性。

要するに：私のシーケンシャル書き込み、使用してのいずれかddまたは（のような...毎日の使用で）ファイルをコピーするときは、となり、擬似ランダム書込み 4つのスレッドを同時実行した後に、ブロックデバイスに暗号化されたデータを書き込むことで同時に作業しているので（悪いです）暗号化（良好）。

軽減策（「古い」カーネル用）

次のように、IOスケジューラキューのキューに入れられたリクエストの量を増やすことにより、悪影響を軽減できます。

echo 4096 | sudo tee /sys/block/sdc/queue/nr_requests

私の場合、これは私の質問で説明した4GBランダムデータテストのスループットのほぼ3倍（約56MB / s）です。もちろん、暗号化されていないIOと比較して、パフォーマンスはまだ100MB / s未満です。

調査

マルチコア blktrace

さらに、LUKS暗号化ブロックデバイスの上部にbtrfsが配置される問題のあるシナリオを調査しました。実際のブロックデバイスに発行される書き込み命令を示すために、次のblktraceように使用しました。

sudo blktrace -a write -d /dev/sdc -o - | blkparse -b 1 -i - | grep -w D

これが何をするかにトレースIO要求（これまで私が理解することができたとして）である/dev/sdcタイプのものである「書き込み」、「そして、人間が読める出力にこれを解析するが、さらなるアクションに出力を制限D（によるとされ、」man blkparse） 「ドライバーにIOが発行されました」。

結果は次のようになりました（マルチコアログの約5000行の出力を参照）。

8,32   0    32732   127.148240056     3  D   W 38036976 + 240 [ksoftirqd/0]
8,32   0    32734   127.149958221     3  D   W 38038176 + 240 [ksoftirqd/0]
8,32   0    32736   127.160257521     3  D   W 38038416 + 240 [ksoftirqd/0]
8,32   1    30264   127.186905632    13  D   W 35712032 + 240 [ksoftirqd/1]
8,32   1    30266   127.196561599    13  D   W 35712272 + 240 [ksoftirqd/1]
8,32   1    30268   127.209431760    13  D   W 35713872 + 240 [ksoftirqd/1]

• 列1：メジャー、マイナー、ブロックデバイス
• 列2：CPU ID
• 列3：シーケンス番号
• 列4：タイムスタンプ
• 列5：プロセスID
• 列6：アクション
• 列7：RWBSデータ（タイプ、セクター、長さ）

これはdd、マウントされたファイルシステムに4GBのランダムデータを作成するときに生成される出力の一部です。少なくとも2つのプロセスが関係していることは明らかです。残りのログは、4つのプロセッサすべてが実際に動作していることを示しています。悲しいことに、書き込み要求はもう順序付けされていません。CPU0が38038416番目のセクターの周りに書き込みを行っている間に、後でスケジュールされるCPU1は35713872番目のセクターの周りに書き込みを行っています。良くないね。

シングルコア blktrace

マルチスレッドを無効にし、CPUの2番目のコアを無効にした後、同じ実験を行いました。もちろん、スティックへの書き込みに関与するプロセッサは1つだけです。しかし、さらに重要なことは、書き込み要求が適切にシーケンシャルであるため、それ以外の場合は同じセットアップで最大170MB / sの書き込みパフォーマンスが達成されることです。

見ていsinglecoreログに出力の約5000行を。

討論

原因と適切なグーグル検索用語がわかったので、この問題に関する情報が表面に浮かんできました。結局のところ、私は最初に気づいたわけではありません。

• 4年前、パッチがマルチスレッドdm-cryptをカーネルにもたらしました。このコミットは、私の調査結果とほぼ一致しています。
• 2年前、書き込み要求の並べ替えを含む、dm-cryptのパフォーマンスの改善についてパッチが議論されました。
• 1年前、このトピックはまだ議論されていました。
• 最近、dm-cryptのソートを可能にするパッチがついにカーネルにコミットされました。
• この現象に関するパフォーマンステスト（これはあまり読みませんでした）が記載された興味深いメールがあります。

現在のカーネルで修正（> = 4.0.2）

私は（後で）カーネルコミットが明らかにこの正確な問題をターゲットにしていることを発見したため、更新されたカーネルを試してみたかったのです。[自分でコンパイルして、すでに存在することを確認した後debian/sid]問題は実際に修正されたことがわかりました。修正が登場した正確なカーネルリリースはわかりませんが、元のコミットは興味のある人に手がかりを与えてくれます。

記録のために：

$ uname -a
Linux t440p 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test bs=1M conv=fsync
4294967296 bytes (4.3 GB) copied, 29.7559 s, 144 MB/s

コミットを作成したMikulas Patockaへの帽子のヒント。