web-dev-qa-db-ja.com

cryptsetupとext4にはどのくらいのストレージオーバーヘッドが伴いますか？

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

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

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を超えるdirの問題は修正されますが、50MB未満のdirの問題は修正されません。

コンテナがディレクトリよりも大きくなければならないそれぞれのバイト数をどのように決定できますか？

encryptionext4dm-cryptcryptsetup
3
fret

LUKSは、主にデータアライメントの理由により、デフォルトでヘッダーに2MiBを使用します。これは、cryptsetup luksDump（セクターではPayload offset:）で確認できます。配置を気にしない場合は、--align-payload=1オプションを使用できます。

ext4に関しては、それは複雑です。そのオーバーヘッドは、ファイルシステムサイズ、iノードサイズ、ジャーナルサイズなどによって異なります。ジャーナルが必要ない場合は、ext2をお勧めします。他のファイルシステムのオーバーヘッドはext*よりも少ない可能性があり、実験する価値があるかもしれません。また、いくつかのmkfsフラグ（-T largefileなど）は、これに置くファイルの種類によっては役立つ場合があります。例えば。ダースのファイルを入れるだけの場合は、100万のiノードでファイルシステムを作成する必要はありません。

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

これはかなり小さいはずです。さらに小さくする必要がある場合は、ファイルシステムの代わりにtar.xzを使用することを検討してください。 tarは、数百GBのデータ（単一のファイルにアクセスするためにすべてを抽出する必要がある）にはそれほど適していませんが、前述のサイズでは問題なく、ほとんどのファイルシステムよりも小さい必要があります...

2
frostschutz

「LUKSには、LUKSヘッダーを格納する1032セクター（セクターは512バイト）のオーバーヘッドがあります。ヘッダーに続いて、暗号化されたデータは、復号化されたデータと同じ量のスペースを直線的に使用します。」

参照： http://glandium.org/blog/?p=139

0
Martin Eve

ファイルシステムにはファイル自体よりも多くのものが含まれているため、ファイルシステムの正確なサイズを予測することは困難です。ディスク使用量に関する微妙な点については、 ディスク使用量を測定する方法が非常に多いのはなぜですか？ を参照してください。特に：

  • 各ファイルは不完全なブロックで終わります。 duを実行するとこれが考慮されますが、-B引数を省略する必要があります。これは、実行するファイルシステムのブロックサイズがコピー先のファイルシステムと同じである場合にのみ適用されます。ファイル。
  • ファイルシステムには、iノードやその他のデータ構造（スーパーブロック、ジャーナルなど）も含まれている必要があります。

ファイルの数を追跡し、その数のiノードを作成し、ブロックのサイズとiノードのサイズを合計すると、ファイルシステムのサイズについての良いアイデアが得られます。しかし、それを本当にタイトにしたい場合は、少し試行錯誤することを期待してください。

最小のext2イメージサイズを見つける最も簡単な方法は、十分な大きさのext4イメージを作成し、resize2fsを使用して縮小することです。

Linuxでリードバックする読み取り専用ファイルシステムを作成している場合は、 squashfs がext4よりも適切です。

Dm-crypt自体にもオーバーヘッドがあります。これは [〜＃〜] faq [〜＃〜] で説明されています。デフォルトでは、cryptsetupはボリュームの先頭にメタデータ用に2MBを予約します（FAQ2.18）。オーバーヘッドはボリュームサイズに依存しません。 FAQ 6.12および6.13は、オーバーヘッドを削減する方法を説明しています。128ビットのキーサイズを選択します（セキュリティのためにそれ以上は必要ありません）。これには、512kBのキースロットが必要です。固定サイズのヘッダー（544B）。可能な限り最小の配置、またはそれに近い配置を選択します。4kBブロックサイズのファイルシステムでは、4kBおよび4kB未満の配置を使用すると、パフォーマンスがわずかに低下すると思います。とにかくそのスケールでは無視できるので、516kBの合計オーバーヘッドのために4kBの配置をお勧めします。ボリュームを作成するときのオプションは次のとおりです。

cryptsetup luksFormat -s 128 --align-payload=8 --key-file $keyFile /dev/loop0
0
Gilles 'SO- stop being evil'