これは極端なケースかもしれませんが、ここでは...
2TBのハードドライブからデータを回復しています。私が使用しなければインストールできずmount -r、重要なディレクトリをコピーするために使用しますrsync --files-from。
時々失敗して再起動する必要があります。ディレクトリツリー全体をキャッシュし、そのキャッシュを使用する方法があることを願っています。複数のマウントにまたがる：つまり、ディスクを再マウントする必要がある場合は、ディスクで追加のルックアップを実行するのではなく、ファイルルックアップ用のキャッシュを提供します。
ddバックアップスペースが不足してディスクを完全にイメージできないとします（または使用）。ddrescue
ベストアンサー1
（また）これを行う唯一の方法はブロック層で動作するため、使用されるファイルシステムとは無関係だと思います。
欲しいものは一種のlvmcacheです。デバイスに設定し、ファイルシステムメタデータ（find /path/to/mountpoint -perm 700 -printf ""）を読み取り、キャッシュデバイスにコピーし、キャッシュデバイスを固定します。
残念ながら、lvmcacheにはそのような凍結機能がないようです。
しかし、同様のことができます。つまり、スナップショットを設定できます。 LVMはボリュームグループ内でのみサポートされているため、これを手動で実行する必要があります。 VGでスナップショットを作成し、関連デバイスの詳細を表示しますdmsetup ls。問題のデバイスがボリュームグループに属するか（LVMデバイスであるか）は重要ではありません。dmsetup tabledmsetup
通常、スナップショットを作成して基本デバイスを引き続き使用します。スナップショットを復元すると、元のデバイスで変更される前に元のデータがスナップショットに書き込まれたため、プライマリデバイスの以前の状態を復元できます。あなたが望むものではありませんか？ソースデバイスへのアクセスを最小化しようとしています。したがって、（新しい）元のデバイスではなくスナップショットデバイスをマウントします。
これにより、メタデータを含むすべてのセクタが変更され、スナップショットデバイスに書き込まれます。 2回書き込んで（データを変更してから元の状態に戻すため）、データ自体がまったく変更されない場合でも、セクタはスナップショットデバイスの一部として保持されます。これは常にスナップショットデバイスから読み取ることを意味します。競合が発生した場合は、dmsetup構成を復元するだけでメタデータの元のデバイスにアクセスできなくなります。
ただし、かなり大きなスナップショットと小さいクラスタサイズが必要になることがあります。ただし、ファイルシステムメタデータ全体を一度にキャッシュする必要はありません。スナップショットを設定し、ディレクトリツリーのメタデータをキャッシュし、そこからすべてのファイルをコピーし、スナップショットを削除し、新しいスナップショットを作成し、次のサブツリーのメタデータをキャッシュできます。dmsetup status使用しているスナップショットスペースの量を確認できます（IIRCを含む）。
inodeに書き込むには、touch /path/to/file特に元の値が必要ない場合は、タイムスタンプ（）を変更できます。あるいは、（おそらく元の値をどこかに書き込んだ後）、たとえばchmod o=rwx /path/to/file ; chmod o= /path/to/fileディレクトリエントリに属するすべてのセクタを書き込むには、すべてのファイルの名前を未使用の名前に置き換えることができます。
unique_suffix=4itxIIq5kyGhMVPJ
mv "$file" "${file}${unique_suffix}"
mv "${file}${unique_suffix}" "$file"
ページキャッシュが変更されていないことを検出するのに十分スマートであるかどうかわからないため、スナップショットが実際に作成されたことを確認できます。
すべてのファイルに対するこれらの操作は、次のコマンドを使用して実行する必要があります（サブディレクトリのみ）。
find /path/to/mountpoint -type f -exec ... + # for chmod and mv
find /path/to/mountpoint -type d -exec ... + # for mv