web-dev-qa-db-ja.com

ecryptfsと多くの小さなファイル-パフォーマンスが悪い?

数十万の小さなファイル、合計約14GBのデータを含むフォルダーがあります。これは私のecryptfs暗号化ホームディレクトリ内のフォルダです。

「du-shフォルダー」の実行には9分以上かかります。暗号化されていない場所に対してcp-ralを実行するには、1時間15分かかります。この期間のCPU負荷は、ほとんどがIOバウンドです(80%がトップ)

「du-shencryptedfolder」の実行には15秒しかかからず、同じ場所へのcp-ralには80秒しかかかりません。 'encryptedfolder'は、暗号化されたファイルを含む/home/.ecryptfs/myname/.Private内のフォルダーです。

このパフォーマンスヒットがどのように発生するのか、私は困惑しています。このフォルダはrsyncを介して毎晩バックアップされますが、現在は2時間以上かかります。 ecryptfsに切り替える前は、truecryptを使用し、バックアップは12分で実行されました。

このシナリオでecryptfsが非常に遅いのはなぜですか? du-shおよびcp-ral操作では、ファイルの内容を復号化する必要はなく、正しいファイル名を見つけるだけです。これをスピードアップする方法はありますか?

追伸:これはUbuntu11.04で動作します

3
Guy

ここにはいくつかの要因があります。

  1. ディレクトリ内のすべてのファイル名のリストを取得するには、下位のファイル名をデコード、解析、および復号化する必要があります。

  2. Duからのstat()呼び出しによりルックアップが発生します。これには、eCryptfs iノードの割り当て、下位ファイルメタデータの一部の読み取り、eCryptfsファイルであることの確認、暗号化されていないファイルサイズの解析が必要です。 。下位ファイルシステムからメタデータを読み取るには、下位ファイルシステムのページキャッシュにページを読み込む必要があることに注意してください。

ECryptfsの設計により、多数のファイルを処理するときに不幸なオーバーヘッドが発生します。設計にもかかわらず、いくつかの改善/強化が行われると確信していますが、コードのこの部分を最適化することは、以前は私の焦点では​​ありませんでした。

3
tyhicks

簡単な答えはそうではないということです。パフォーマンスへの影響は、encryptfsが遅いことによるものではなく、非常に多数のiノードを割り当ててディスクメンテナンスを実行し、ファイルに関連付けられているすべてのメタデータを1つずつディスクに配置する必要があることによるものです。

フォルダが毎晩バックアップされる場合は、最初にディレクトリ全体を「tar」し、結果のファイルを圧縮してから暗号化する方が便利な場合があります(暗号化されたファイルでは圧縮が機能しないため、暗号化してから圧縮しないでください)。このようにして、バックアップが著しく小さくなり、作成と移動がはるかに高速になります。

0
SecurityMatt