ecryptfsの書き込みパフォーマンスが悪い

私はecryptfsとdm-cryptで少しベンチマークを行い、いくつかの興味深い結果を得ました。以下はすべて、Btrfsファイルシステムで行われ、データ同期を強制ddするconv=fdatasyncオプションを使用して、〜700MBのファイルをRAMディスクとの間でコピーしました。各テストの前にディスクキャッシュがクリアされました。

No encryption:
 read - 165MB/s
 write - 120MB/s
ecryptfs:
 read - 125MB/s
 write - 15MB/s
dm-crypt:
 read - 150MB/s
 write - 115MB/s
dm-crypt + ecryptfs:
 read - 120MB/s
 write - 15MB/s

現在、暗号化は生のファイルシステムよりも遅いことを理解していますが、ecryptfsによる書き込みパフォーマンスの大幅な低下は予想していませんでした。データの同期を強制しているという事実により、このテストは非現実的になりますか？または、書き込みをより速く動作させるためにecryptfsに渡すことができるオプションはありますか？

私はecryptfsでファイル名の暗号化を使用していましたが、それ以外はすべてデフォルトに設定されていました。

読み取りddに関するmanページfdatasync：physically write output file data before finishingので、物理的に「一度だけ」データを書き込みます（「Xブロックまたはバイトごとにフラッシュを強制せず、最後に1回フラッシュする」と読みます）。ddテストに使用している場合、最も正確な結果を得るための最良の方法です。それどころか、その特定のフラグを使用しないと、結果が非​​現実的になります。それを省略すると、dd単にデータをコピーしているだけなので、暗号化自体の時間を見逃します。

それにも関わらず、私はあなたの結果に関して何かが起こっていると思っていましたが、この記事はほとんど同じことを示しています：ecryptfsは痛々しいほど遅いです。そして、テスト（コピーされる単一のファイル）はecryptfsの最良のシナリオです！

ecryptfsはすべてのクリアテキストバージョンに対して暗号化されたファイル（メタデータを含むカスタムヘッダーを含む）を書き込むため、小さなファイルが多数あると、パフォーマンスがさらに低下します。

ただし、ecryptfsには利点があります。暗号化を失うことなく、暗号化されたファイルをすぐに送信できます。バックアップ（暗号化されたデータをバックアップする場合）は、データと同じ大きさのファイルのみをコピーするため、高速になります（増分ファイルの場合は、変更されたファイルのみをコピーするため、さらに高速になります）。

一方、dm-cryptははるかに高速かもしれませんが、暗号化をそのまま維持するには、コンテナ全体（ファイルシステム全体）を送信する必要があります。また、バックアップはコンテナ全体で構成され、ほとんどの場合、増分バックアップを実行できません。

私は暗号化されたデータを保持するために両方の方法（同じツールではありません）を使用しました（そして今でも使用しています）：ファイルベース（ecryptfs）は、PC間のDropboxなどのオンラインホスティングサービスを介して簡単に同期を維持できますが、変更を行うと、下層のファイルシステムでいくつかの問題が発生しました（ファイルを書き込むことができると仮定し、ファイルシステムの制限に関連する問題は全体を分割する傾向があります）。私はブロックデバイス暗号化を好む：私はそれらを単純なパーティションとして扱うので、制限と問題はそれほどひどく壊れない。唯一の欠点は、コンテナをコピーすることです。