☰

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サイズには適しており、ほとんどのファイルシステムより小さくなければなりません。

おすすめ記事