LUKS + ext4 が遅い原因を cryptsetup benchmark と rsync で切り分ける

LUKS + ext4 の速度低下を一つの原因で説明しない

LUKS + ext4 のバックアップが遅い場合、最初から LUKS を原因と決めることはできません。暗号化方式だけでなく、ext4 のメタデータ更新、ファイル数、HDD の記録方式、USB 接続、初回投入か差分同期かという条件が実効速度を変えるためです。

実際に、TrueCrypt + FAT から LUKS + ext4 へ移行した際、2.5-inch 2 TB HDD では実用に耐えない速度低下が発生した一方、同じ LUKS + ext4 を使った 2.5-inch 5 TB HDD と SSD では、同じ程度の問題は発生しませんでした[1]。

この違いは、次の順序で切り分けます。

1. デバイス、ファイルシステム、ソフトウェアの条件を記録する
2. cryptsetup benchmark で暗号計算の処理能力を確認する
3. 大容量単一ファイルで連続書き込み性能を測る
4. 小ファイル群を rsync してメタデータ更新を含む性能を測る
5. 暗号化なしの ext4、別媒体、別 USB 接続と比較する
6. カーネルログで I/O エラーや USB リセットを確認する

結論を先に示すと、cryptsetup benchmark が実媒体より十分に速く、大容量単一ファイルは速いのに小ファイル群だけが遅い場合、暗号計算が主な律速である可能性は低くなります。この場合は、ext4 の journal、inode、ディレクトリ更新と HDD のランダム I/O を優先して確認します。

検証条件を固定する

性能値を比較する前に、測定対象を特定します。/dev/sdb のようなデバイス名は接続順によって変わるため、型番、容量、ファイルシステム、マウントポイントも併記します。

以下では、検証用マウントポイントを環境変数に設定します。

TEST_MOUNT=/mnt/backup-test
MAPPING_NAME=backup-test
BLOCK_DEVICE=/dev/sdb

実環境に合わせて値を変更します。特に BLOCK_DEVICE は、次の確認が終わるまで設定値を信用せず、実際のデバイスと照合します。

OS とコマンドのバージョンを記録する

date --iso-8601=seconds
uname -r
cryptsetup --version
rsync --version

カーネル、cryptsetup、rsync のバージョンと測定日時を記録します。別のホストで再測定した場合に、媒体以外の差を追跡するためです。

デバイスとマウント状態を確認する

lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN,FSTYPE,MOUNTPOINTS
findmnt -no SOURCE,FSTYPE,OPTIONS "$TEST_MOUNT"
sudo cryptsetup status "$MAPPING_NAME"
df -h "$TEST_MOUNT"

lsblk の ROTA が 1 なら回転媒体、0 なら非回転媒体として認識されています。ただし、この値だけでは SMR と CMR を判別できません。SMR はトラックを一部重ねて高密度化する記録方式で、長時間の書き換えや細かい更新が混在すると、内部再配置によって速度が低下する場合があります。

findmnt では、対象が ext4 であることと、実際のマウントオプションを確認します。cryptsetup status では、対象のマッピング、暗号方式、鍵サイズ、セクターサイズなどを記録します。

セクターサイズも比較する場合は、暗号化されたマッピングと下位デバイスをそれぞれ確認します。

sudo blockdev --getss "/dev/mapper/$MAPPING_NAME"
sudo blockdev --getpbsz "/dev/mapper/$MAPPING_NAME"
sudo blockdev --getss "$BLOCK_DEVICE"
sudo blockdev --getpbsz "$BLOCK_DEVICE"

検証表には少なくとも次の条件を残します。

項目	記録内容
ホスト	OS、カーネル、CPU
暗号化	cryptsetup のバージョン、暗号方式、鍵サイズ
ファイルシステム	ext4、マウントオプション
媒体	製品型番、容量、HDD または SSD
接続	SATA、USB、USB ブリッジ、ハブの有無
作成状態	mkfs.ext4 直後か、継続利用中か
処理	初回投入、全量コピー、差分同期
データ	総容量、ファイル数、ディレクトリ数

cryptsetup benchmark で暗号計算を確認する

最初に暗号アルゴリズム単体の処理能力を測ります。

sudo cryptsetup benchmark

cryptsetup benchmark はメモリー上で暗号処理と鍵導出関数を測る参考値です。実ストレージ、ext4、USB、HDD の待ち時間は含まれず、結果から実際の暗号化ストレージ速度を直接予測することはできません[2]。

確認するのは、使用中の暗号方式に近い行です。たとえば LUKS 側が AES-XTS を使用している場合は、AES-XTS の暗号化速度と復号速度を記録します。

判断は次のように行います。

結果	読み方
benchmark が実媒体の数倍以上速い	暗号計算以外が主な律速である可能性が高い
benchmark と実媒体の速度が近い	暗号計算を含めて追加確認が必要
benchmark 自体が遅い	CPU、暗号支援、暗号方式、カーネル構成を確認する

たとえば benchmark が 1 GiB/s を超えている一方、実コピーが 20 MiB/s しか出ない場合、数値差を LUKS の暗号計算だけで説明することは困難です。次に実媒体の I/O を測ります。

大容量単一ファイルで連続書き込み性能を測る

大容量単一ファイルの試験では、ディレクトリや inode の更新回数を抑え、媒体の連続書き込みに近い性能を確認します。ここで作成するファイルは検証後に削除できる一時データですが、既存ファイルと名前が衝突しない専用ディレクトリを使います。

TEST_DIR="$TEST_MOUNT/luks-ext4-test"
mkdir -p "$TEST_DIR"
df -h "$TEST_MOUNT"

次の例では 4 GiB を書き込みます。

/usr/bin/time -p dd \
  if=/dev/zero \
  of="$TEST_DIR/large-file.bin" \
  bs=1M \
  count=4096 \
  conv=fdatasync \
  status=progress

conv=fdatasync を付けるのは、dd の終了前にファイルデータの書き出しを完了させるためです。オペレーティングシステムのページキャッシュへ渡した時点だけを測るより、実媒体の待ち時間を結果へ反映しやすくなります。

4 GiB では媒体側のキャッシュが支配的になる場合があります。その場合は空き容量を確認したうえで試験サイズを増やし、開始直後と終了前の速度も比較します。初期だけ速く、その後に大きく低下するなら、HDD のキャッシュ枯渇、SMR の内部再配置、温度、USB ブリッジの動作が候補になります。

実効速度は次の式で統一します。

実効速度 = 書き込んだバイト数 / 経過秒数

大容量単一ファイルでも遅い場合は、媒体、接続、flush 処理を優先して調べます。この試験が速く、次の小ファイル試験だけが遅い場合は、ファイルシステムと I/O パターンの影響が大きいと判断できます。

小ファイル群でメタデータ更新性能を測る

バックアップ対象が多数の小ファイルを含む場合、総容量だけでは処理量を表せません。ファイルごとに inode、ディレクトリエントリー、所有者、権限、サイズ、更新時刻が変わり、ext4 の journal も更新されます。原典の事例では、暗号化層、ext4 のメタデータ、媒体、USB 接続、同期方式を別の層として扱わなければ、原因を一つに絞れないことを確認しています[3]。

実際のバックアップに近い既存のテストデータを用意し、同じ内容を各比較対象へ転送します。テスト元はローカルの読み取り性能が十分に高い SSD などへ置き、転送元が律速しないようにします。

TEST_SOURCE=/srv/backup-test-source
TEST_DEST="$TEST_DIR/small-files"

find "$TEST_SOURCE" -type f | wc -l
find "$TEST_SOURCE" -type d | wc -l
du -sh "$TEST_SOURCE"
mkdir -p "$TEST_DEST"

空の転送先に対する初回コピーを測ります。

/usr/bin/time -p rsync \
  -a \
  --stats \
  "$TEST_SOURCE/" \
  "$TEST_DEST/"

rsync --stats の出力から、総ファイル数、作成ファイル数、転送ファイル数、総ファイルサイズ、実転送量を記録します。転送量が少なくてもファイル数が多い場合は、MB/s だけでなく、1 秒あたりの処理ファイル数も比較します。

初回コピーと差分同期は別のワークロードです。差分同期では、ファイル一覧の取得、属性比較、ディレクトリ走査が加わります。削除を含む同期ではさらにメタデータ更新が増えるため、削除なしの試験と同列に扱いません。

結果は次のように読みます。

大容量単一ファイル	小ファイル群	判断
速い	遅い	ext4 のメタデータ更新と HDD のランダム I/O を疑う
遅い	遅い	媒体、USB 接続、SMR、flush を疑う
速い	速い	本番データ固有のファイル数、差分判定、削除処理を確認する
時間とともに低下	時間とともに低下	キャッシュ枯渇、SMR 内部再配置、熱を確認する

比較試験では一度に一つの条件だけを変える

原因を分けるには、同じテストデータとコマンドを使い、比較ごとに変更する条件を一つに限定します。

比較	固定する条件	分離したい要因
LUKS + ext4 と暗号化なし ext4	媒体、接続、データ	暗号化層
HDD と SSD	LUKS、ext4、データ	媒体性能
USB ポートまたはケーブル	媒体、LUKS、ext4、データ	接続経路
大容量単一ファイルと小ファイル群	媒体、LUKS、ext4	I/O パターン
ext4 作成直後と継続利用中	媒体、LUKS、データ	遅延初期化

暗号化なし ext4 との比較には、データを消去しても問題のない専用媒体または専用領域を使います。mkfs.ext4 や cryptsetup luksFormat は既存データを破壊するため、本番媒体に対する性能確認として実行してはいけません。

異なる HDD を比べる場合は、暗号化だけを分離した比較にはなりません。製品型番、容量、内部ドライブ、記録方式、ファームウェア、USB ブリッジ、キャッシュ、経年状態が同時に変わるためです。同じ 2.5-inch HDD という分類や、公称最大転送速度だけを比較条件として扱わないようにします。

ext4 作成直後の初回投入を分けて測る

mkfs.ext4 の直後は、inode table の遅延初期化がバックグラウンドで残っている場合があります。この状態で大量のファイルを投入すると、ファイル作成、ディレクトリ更新、journal、初期化処理が同じ媒体上で競合します[1]。

次の 2 条件を分けて記録します。

1. ext4 の作成直後に開始した初回投入
2. 初期化後または継続利用中に行った同一データの投入

初回だけが遅い場合、通常運用時の性能と初期構築時の性能を分けて評価します。初回投入に 24 時間以上かかり、バックアップ更新の間隔へ収まらないなら、理論上利用できる構成でも運用上は採用できません。

カーネルログから接続異常を確認する

測定開始時刻と終了時刻を記録し、その時間帯のカーネルログを確認します。

sudo dmesg --ctime | tail -n 200

systemd を使用している環境では、期間を限定できます。

sudo journalctl -k --since "1 hour ago"

次の文字列を確認します。

I/O error
Buffer I/O error
reset
device offline
USB disconnect
uas
EXT4-fs error
Remounting filesystem read-only

USB リセット、切断、I/O エラーが記録されている場合は、性能調整より先にケーブル、ポート、ハブ、電源、外付け筐体、媒体を確認します。SMART が正常であっても、小ファイルを大量に書き込む性能が十分であるとは限りません。逆に、ログにエラーがないことも、高い処理性能の証明にはなりません。

測定結果から運用方法を決める

一連の結果を次の表へまとめます。

観測結果	主に疑う層	次に確認する項目
cryptsetup benchmark 自体が遅い	CPU、暗号支援、暗号方式	CPU 機能、カーネル、暗号設定
benchmark は速いが連続書き込みが遅い	HDD、SMR、USB、flush	別媒体、別ポート、長時間推移
連続書き込みは速いが小ファイルだけ遅い	ext4、journal、ランダム I/O	ファイル数、ディレクトリ数、同期条件
初回投入だけ遅い	ext4 の遅延初期化	初期化後の再測定
時間経過とともに急激に低下する	キャッシュ枯渇、SMR、熱	長時間測定、別型番
カーネルログにリセットがある	USB、電源、筐体	ケーブル、ポート、電源、媒体交換
暗号化なし ext4 でも遅い	ファイルシステム、媒体、接続	別媒体、別接続
SSD では速く HDD だけが遅い	HDD の IOPS、seek、SMR	HDD の役割変更

LUKS + ext4 を採用できるかどうかは、設定の正しさだけでなく、実際のバックアップが運用時間内に終わるかで決まります。SSD や性能に余裕のある HDD で必要な速度が出るなら、LUKS + ext4 を維持できます。一方、小ファイル同期で著しく失速する 2.5-inch HDD は、更新頻度の低いアーカイブや読み取り中心の媒体へ役割を変更した方が安全です。

速度を上げるためだけに ext4 の journal、write barrier、同期処理を無効化すると、障害時の整合性という採用理由を損ないます。保護機能を削る前に、媒体の変更、更新頻度の見直し、バックアップ単位の集約、SSD への切り替えを検討します。

暗号化媒体の速度は、暗号アルゴリズム名だけでは決まりません。cryptsetup benchmark、連続書き込み、小ファイル同期、比較用媒体、カーネルログを順に確認すると、LUKS、ext4、HDD、USB のどこを見直すべきかを実測から判断できます。

参考文献

1. id774, 2.5-inch HDD で LUKS + ext4 が遅くなった理由（2026-05-24）. https://blog.id774.net/entry/2026/05/24/4801/
2. cryptsetup project, cryptsetup-benchmark(8)（2025-08-09）. https://man7.org/linux/man-pages/man8/cryptsetup-benchmark.8.html
3. id774, 自由ソフトウェアだけで暗号化媒体をどこまで扱えるか（2026-06-03）. https://blog.id774.net/entry/2026/06/03/4849/