Dal*_*ter 11 filesystems ext3 versioning git
我一直在考虑版本控制文件系统。这是一个杀手级功能，我看过 Wayback、ext3cow、zfs、fuse 解决方案，或者只是 cvs/svn/git 覆盖。
我认为 ext3cow 是满足我要求的模型。透明、高效，但我可以不用额外的ls abc@timestamp功能。只要我以某种方式对我的文件进行自动化、透明的版本控制。
它可以是瞬时的，也可以基于 10 秒、30 秒、1 米、5 米、15 米等间隔的快照。只是可以有效处理给定目录中各种大小的数千个文件的东西，大多数文件很小，但也有一些超过 100m 到 1gb。
ZFS 并不是一个真正的选项，因为我在 linux 上（并且不想通过保险丝使用它，因为我已经有一个我想要版本的 ext3 设置，而不是新的东西）。
有哪些解决方案？
经过8年的搜索，我发现SVNFS由马可河米兰（这是由同一个名字从旧的项目不同的约翰·麦登[哪一个做不同的事情]）。这个SVNFS在 r/w 操作中透明地使用svn：
我没有创建自己进行版本控制的文件系统，而是使用了现有的版本控制工具 subversion，并使其使用透明。优点是这个文件系统不需要你学习一个新工具，如果你知道subversion
它是用 Python 编写的并使用 FUSE：
现在您通过调用附加的脚本来启动版本控制文件系统：
python svnfs.py -o svnroot=/home/marco/svnfiles /home/marco/myfiles
一旦一切正常，您应该能够获得两个目录的列表并看到内容相同。
现在，如果您在任一目录中创建（几乎）任何文件，它也会显示在围栏的另一侧。最大的不同是，如果你在 myfiles 目录中创建一个文件，它会自动置于版本控制之下（反之则不然）。
在示例中SVNFS为 repo 使用单独的目录。虽然我没有测试过。对于我的需要，我希望在我的工作目录中有存储库。
请参阅 Reiser 4。文件是目录。
例如：
diff -u main.C main.C/r/123或访问属性
cat main.C/p/svn-eolstyle
echo "foobar" > main.C/p/my-property
似乎最好遵循该模型，因为一个主要的文件系统已经在走这条路线。
——保罗·奎尔纳
不过我也没查过。
两年前，我进一步搜索，找到了用于生成可堆叠文件系统的项目FiST，并联系了教授。埃雷兹撒督的州立大学石溪分校谁是顾问/导师的项目称为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/）。
所以这里没有工作项目，尽管可堆叠文件系统的概念对我来说似乎很好。会有人喜欢，开始基于ONF项目wrapfs，通知我请:)