☰

cryptsetupとext4はどのくらいのストレージオーバーヘッドをもたらしますか？

tag-icon • tag-icon encryption ext4 dm-crypt cryptsetup
cryptsetupとext4はどのくらいのストレージオーバーヘッドをもたらしますか？

ext4ファイルシステムを持つコンテナのディレクトリコンテンツを暗号化するためにcryptsetupを使用したいと思います。コンテナのサイズはできるだけ小さく、一度だけ書き込んでバックアップするので、必要なだけ大きくする必要があります。

最初の試み：コンテナサイズをコンテンツサイズに合わせて設定します。

dirsize=$(du -s -B512 "$dir" | cut -f 1)
dd if=/dev/zero of=$container count=$dirsize
losetup /dev/loop0 $container
fdisk /dev/loop0 # 1 Partition with max possible size
cryptsetup luksFormat --key-file $keyFile /dev/loop0
cryptsetup luksOpen --key-file $keyFile /dev/loop0 container
mkfs.ext4 -j /dev/mapper/container
mkdir /mnt/container
mount /dev/mapper/container /mnt/container
rsync -r "$dir" /mnt/container

Rsyncはデータを保持するのに十分なスペースを返しません。暗号化とファイルシステムには少しオーバーヘッドが必要であるため、合理的に見えます。

相対オフセットを試してみました。

dirsize=$(($dirsize + ($dirsize + 8)/9))

これにより、100 MBを超えるディレクトリの問題は解決されますが、50 MBより小さいディレクトリの問題は解決されません。

コンテナがディレクトリより大きくなければならない対応するバイト数を決定する方法は？

答え1

LUKS は、デフォルトで照合のためにヘッダーに 2MiB を使用します。cryptsetup luksDump（Payload offset:セクタから）を使用して確認できます。ソートに興味がない場合は、この--align-payload=1オプションを使用できます。

それに関してはext4複雑です。オーバーヘッドは、ファイルシステムサイズ、inodeサイズ、ログサイズなどによって異なります。ジャーナルが不要な場合は好むかもしれませんext2。他のファイルシステムはオーバーヘッドが少ないext*ため、試してみる価値があります。また、そのエントリに追加するファイルの種類によっては、一部のmkfsフラグ（類似または類似）が役に立つ場合があります。-T largefileたとえば、12個のファイルのみを保存したい場合は、100万個のinodeを持つファイルシステムを作成する必要はありません。

コンテナを最小サイズにするには、より大きなコンテナから始めて、resize2fs -M最小サイズに縮小します。その後、truncateそのサイズとLUKSのコンテナを使用できます。Payload offset:

これはほとんど小さいでしょう。小さいサイズが必要な場合は、tar.xz代わりにファイルシステムを使用することをお勧めします。数百GBのデータ（単一のファイルにアクセスするにはすべてを抽出する必要があります）には適していませんが、言及したtarサイズには適しており、ほとんどのファイルシステムより小さくなければなりません。

答え2

「LUKSには、LUKSヘッダを格納するための1032個のセクタ（1セクタは512バイト）のオーバーヘッドがあります。

望むより：http://glandium.org/blog/?p=139

答え3

ファイルシステムにはファイル自体以上のコンテンツが含まれているため、ファイルシステムの正確なサイズを予測することは困難です。バラよりディスク使用量を測定する方法はなぜそんなに変わりますか？ディスク使用量に関していくつかの微妙さがあります。特に：

  • すべてのファイルは不完全なチャンクで終わります。実行時にduこれを考慮-Bしますが、その引数を省略する必要があり、実行中のファイルシステムがファイルをコピーするファイルシステムと同じブロックサイズを持つ場合にのみ適用されます。
  • ファイルシステムには、inodeやその他のデータ構造（スーパーブロック、ログ...）も含める必要があります。

ファイル数と生成されたinodeの数を追跡し、ブロックサイズとinodeサイズを追加すると、ファイルシステムのサイズを大まかに把握できます。しかし、非常に厳密に適用するには試行錯誤が必要です。

最小のext2画像サイズを見つける最も簡単な方法は、十分に大きいext4画像を作成してresize2fs縮小することです。

Linuxで再読み込みできる読み取り専用ファイルシステムを作成する場合カボチャのファイルシステムext4より良い選択になります。

Dm-crypt自体にもオーバーヘッドがあります。これはよくある質問。デフォルトでは、cryptsetup2MBはメタデータ用にボリュームの先頭に予約されています（FAQ 2.18）。オーバーヘッドはボリュームサイズとは関係ありません。 FAQ 6.12および6.13では、オーバーヘッドを減らす方法について説明します。 128ビットのキーサイズ（セキュリティの目的でそれだけ必要）を選択するには、固定サイズのヘッダ（544B）に加えて512kBのキースロットが必要です。可能な最小のソートを選択するか、それに近いものを選択します。ブロックサイズが4kBのファイルシステムでは、4kB未満のソートを使用するとパフォーマンスの低下が減少し、4kBは無視できます。したがって、合計オーバーヘッドを得るために4 kBのアライメントを使用することをお勧めします。516kB。ボリューム作成時のオプションは次のとおりです。

cryptsetup luksFormat -s 128 --align-payload=8 --key-file $keyFile /dev/loop0

関連情報