私はファイルシステムのバージョン管理について長い間考えてきました。これはキラー機能であり、Wayback、ext3cow、zfs、fuseソリューション、または単にcvs / svn / gitオーバーレイを見てきました。
ext3cowを要件のモデルと考えています。透過的で効率的ですが、追加ls abc@timestamp機能なしで実行できます。何らかの形でファイルの自動化された透過的なバージョン管理を取得している限り。
瞬間的なものでも、10秒、30秒、1分、5分、15分などの間隔でのスナップショットに基づいたものでもかまいません。特定のディレクトリにある数千のファイルをさまざまなサイズで効率的に処理します。 100メートルから1ギガバイト以上。
私はLinuxを使用しているので、ZFSは実際にはオプションではありません（新しいものではなく、バージョン管理したいext3セットアップがすでにあるので、ヒューズを介して使用することを好まないでしょう）。
どんなソリューションがありますか？
回答:
8年間の検索の後、Marco R. GazzettaによるSVNFSを見つけました（John Maddenによる同名の古いプロジェクトとは異なります）。このSVNFSは、r / w操作でsvnを透過的に使用します。
独自のバージョン管理を行うファイルシステムを作成する代わりに、既存のバージョン管理ツールであるsubversionを使用し、その使用を透過的にしました。利点は、Subversionを知っていれば、このファイルシステムで新しいツールを学ぶ必要がないことです。
Pythonで書かれており、FUSEを使用しています。
次に、添付のスクリプトを呼び出して、バージョン管理ファイルシステムを起動します。
python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles
すべてがうまくいけば、両方のディレクトリのリストを取得して、内容が同じであることを確認できるはずです。
これで、いずれかのディレクトリに（ほぼ）任意のファイルを作成すると、そのファイルはフェンスの反対側にも表示されます。大きな違いは、myfilesディレクトリにファイルを作成すると、自動的にバージョン管理下に置かれることです（逆は当てはまりません）。
この例では、SVNFSはリポジトリ用に別のディレクトリを使用します。私はそれをテストしていませんが。必要に応じて、作業ディレクトリにリポジトリを作成したいと思います。
4年前にReiser4のバージョン管理機能への参照も見つけました。
Reiser 4を参照してください。ファイルはディレクトリです。
例えば：
diff -u main.C main.C/r/123またはプロパティにアクセスする
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
主要なファイルシステムはすでにそのルートを進んでいるので、そのモデルに従うのが最善だと思われます。
-ポール・ケルナ
しかし、私もチェックしていません。
2年前、私はさらに検索に行き、スタッカブルファイルシステムを生成するプロジェクトFiSTを見つけ、教授に連絡しました。Stony Brook UniversityのErez Zadokは、ずっと前にversionfsと呼ばれるプロジェクトのアドバイザー/メンターでした。引用：
http://www.fsl.cs.sunysb.edu/docs/versionfs-fast04/
http://www.fsl.cs.sunysb.edu/docs/versionfs-msthesis/versionfs.pdf
ユーザーは自分のバージョンを簡単かつ効率的に管理できます。Versionfsは、一般的なユーザーのようなワークロードに対して4％以下のオーバーヘッドでこの機能を提供します。Versionfsを使用すると、ユーザーは保持ポリシーと保存ポリシーを使用して、保持するバージョンと保存方法の両方を選択できます。ユーザーは、フルコピー、圧縮コピー、ブロックデルタなど、個々のニーズに最適なスペースとパフォーマンスのトレードオフを選択できます。ユーザーはバージョンを制御できますが、管理者は最小値と最大値を強制し、ユーザーに適切なデフォルトを提供できます。
さらに、libversionfsを使用することにより、変更されていないアプリケーションはバージョンを検査、操作、および回復できます。ユーザーは、使い慣れたツールを実行するだけで、以前のファイルバージョンにアクセスすることができます。ユーザーに個別のコマンドを学んだり、システム管理者にファイルシステムの再マウントを求めたりする必要はありません。libversionfsがないと、以前のバージョンはユーザーから完全に隠されます。
最後に、Versionfsは、過去のシステムで採用されていた単純なコピーオンライトを超えて、コピーオンチェンジを実装しています。最初は、古いページと新しいページの比較が高すぎると予想していましたが、システム時間の増加は、変更されていないブロックの書き込みに関連するI / OとCPU時間の減少によって相殺される以上です。より高価なストレージポリシー（圧縮など）を使用する場合は、変更時コピーがさらに便利です。
私にとっては非常に興味深いように見えましたが、プロジェクトに携わった人たちに連絡をとると、ソースコードの場所が知られていないことがわかりました。教授自身がメールで述べた：
Versionfsのコードは現在非常に古く、カーネル2.4でのみ機能していました。スタック可能なバージョン管理f / sが必要な場合は、最初から（おそらくwrapfsに基づいて）記述する必要があります（wrapfs.filesystems.org/を参照）。
スタック可能なファイルシステムの概念は私にとってとてもいいように思えますが、ここには実用的なプロジェクトはありません。誰もwffsに基づいてプロジェクトを開始したいですか、私に通知してください:)
gitfsを確認できます。gitベースのFUSEファイルシステムで、非常に安定しており、非常に使いやすいです。
基本的に、それはgitのオーバーレイです。ファイルまたはディレクトリを更新するたびに、その変更でコミットが作成されます（アーカイブを解凍しても100コミットにならないように、コミットをバッチ処理することを認識しています）。また、リモートを同期し、「常に鉱山を受け入れる」戦略を使用して競合をマージすることも知っています。
マウントすると、currentとhistoryの 2つのディレクトリが表示されます。
├── current
│ ├── test1.md
│ ├── test2.md
│ ├── test3.md -> current/test2.md
│ ├── test4.md
│ └── test_directory
└── history
├── 2014-11-23
│ ├── 20-00-21-d71d1579a7
│ │ └── testing.md
│ └── 20-42-32-7d09611d83
│ ├── test2.md
│ └── testing.md
├── 2014-12-08
│ ├── 16-38-30-6d6e71fe47
│ │ ├── test2.md
│ │ └── test1.md
詳細については、このページをご覧ください。
bupは有望に見えます。
ここでの古い議論：http : //lwn.net/Articles/380983/
rsnapshotを試してみてください-私は自分で使っていませんが、@ファイルレベルの重複排除システムを探しているときにつまずきました。
R1Softのホットコピーをご覧ください。
http://www.r1soft.com/tools/linux-hot-copy/
これは、LVMを使用せずに標準システムのコピーオンライトスナップショットを提供するカーネルモジュールです。私にとってはかなりうまく機能しており、再起動せずにインストールできます。