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]。

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

デバイス、ファイルシステム、ソフトウェアの条件を記録する
cryptsetup benchmark で暗号計算の処理能力を確認する
大容量単一ファイルで連続書き込み性能を測る
小ファイル群を rsync してメタデータ更新を含む性能を測る
暗号化なしの ext4、別媒体、別 USB 接続と比較する
カーネルログで 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 条件を分けて記録します。

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

初回だけが遅い場合、通常運用時の性能と初期構築時の性能を分けて評価します。初回投入に 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 のどこを見直すべきかを実測から判断できます。

参考文献

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