私はファイルシステムのバージョン管理について長い間考えてきました。これはキラー機能であり、Wayback、ext3cow、zfs、Fuseソリューション、またはcvs/svn/gitオーバーレイだけを見てきました。
私はext3cowを私の要件のモデルと考えています。透過的で効率的ですが、追加のls abc@timestamp
機能なしで実行できます。どういうわけか、ファイルの自動化された透過的なバージョン管理を取得する限り。
瞬時の場合もあれば、10秒、30秒、1分、5分、15分などの間隔のスナップショットに基づく場合もあります。特定のディレクトリ内のさまざまなサイズのすべての数千のファイルを効率的に処理するものです。 100mから1GB以上。
私はLinuxを使用しているので、ZFSは実際にはオプションではありません(新しいものではなく、バージョン管理したいext3セットアップがすでにあるため、Fuseを介して使用したくない)。
どのような解決策がありますか?
LVMを使用してファイルシステムをラップする場合は、基盤となる論理ボリュームレイヤーを使用してスナップショットボリュームを作成できます。これは非常に単純なプロセスであり、バックアップや元に戻すなどの標準的な「スナップショット」に驚くほど効果的ですrm -fr
おっと。
8年間の 検索 私は[〜#〜] svnfs [〜#〜]byMarco R.Gazzettaを見つけました(これは、同じ名前の古いプロジェクトとは異なります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への参照 のバージョン管理機能を見つけました:
Reiser4を参照してください。ファイルはディレクトリです。
例:
diff -u main.C main.C/r/123
またはプロパティにアクセスするには
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
主要なファイルシステムがすでにそのルートを進んでいるので、そのモデルに従うのが最善のようです。
-ポール・ケルナ
しかし、私もそれをチェックしていません。
2年前、私はさらに検索を行い、スタック可能なファイルシステムを生成するためのプロジェクトFiSTを見つけ、教授に連絡しました。Erez Zadokofストーニーブルック大学ずっと前に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/を参照)。
したがって、スタック可能なファイルシステムの概念は私には非常に良いように思えますが、ここには作業プロジェクトはありません。 fwrapfsに基づいてプロジェクトを開始したい人はいますか?私に知らせてください:)
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を使用せずに標準システムのコピーオンライトスナップショットを提供するカーネルモジュールです。それは私にとってかなりうまく機能していて、再起動せずにインストールできます。