写在前面的话：
最近忙着和老黄做一些开源JAVA项目的工作，很久没有为搞FreeBSD的朋友做什么贡献了。这两天正好比较清闲了，看到bsdforum.org上发
表的一篇core team成员的maillist，觉得非常的有意义，翻译过来让大家了解一下FreeBSD未来发展的一个动态。这篇文章正好提到了广大
FreeBSD用户最为关心的问题，vinum的前途。我一直希望FreeBSD能在卷管理上能有更多的建树。因为卷管理器对于UNIX来说是一项非常重要的
功能，如果FreeBSD想真正在企业级应用上取得一些进展，除了SMP以外恐怕最重要的就是卷管理器了。FreeBSD并不是没有卷管理器的，本文提
到的Vinum就是。但是这个卷管理器一直处于一种实验的阶段，很多功能也并不是能令人满意的。现在由于GEOM的发展，使得Vinum的处境更加
的尴尬。因为一旦使用GEOM的话，vinum就彻底作废了。这对于Vinum来说不能不是一种困境，不过反过来说也许会是一种促进，使得core team
能再次的努力完善vinum的功能。能让vinum达到一个令大家满意的程度。我真的非常期待这一天的到来。
Vinum和GEOM：在FreeBSD上的未来
FreeBSD开发小组的Greg Lehey最近对Vinum和GEOM在FreeBSD上的未来进行了探讨。Greg提到GEOM的出现与原来的Vinum提供的特性和功能有一
些冲突。在另一方面GEOM和Vinum直接不仅仅是存在不同，而且还存在一些不兼容的问题。对于GEOM的开发已经造成Vinum的很多功能变得很鸡
肋了。例如，现在看来已经不可能把swap装载在Vinum的卷上了，这是由于对swapon()的一些修改必须使用GEOM的原因。Vinum卷管理器是一个
实现虚拟磁盘驱动器的块设备驱动。GEOM是一个灵活的磁盘I/O请求转换架构。举个例子来说，GBDE试验性磁盘加密功能就是基于GEOM的。
[Read more]
-------------------------------------
Date: Wed, 7 Jan 2004 16:52:52 +1030
From: Greg 'groggy' Lehey <grog@FreeBSD.org>
To: FreeBSD Architecture Mailing List <arch@FreeBSD.org>
Subject: Vinum and GEOM: the future
GEOM的出现与原来的Vinum提供的特性和功能有一些冲突。在另一方面GEOM和Vinum直接不仅仅是存在不同，而且还存在
一些不兼容的问题。对于GEOM的开发已经造成Vinum的很多功能变得很鸡肋了。例如，现在看来已经不可能把swap装载在Vinum的卷上了，这是
由
于对swapon()的一些修改必须使用GEOM的原因。
Vinum当时编写的时候，设计的是不能在其他格式上使用。但是随着GEOM的
出现，矛盾出现了。我们应该怎样对待Vinum？显然有以下一种选择：
1.放弃它。这是一种保留意见，应该还有更好的办法。
2.与GEOM同时存在，并且使得swapon()同时具备使用两种平台的代码。
3.调整它以适应GEOM。
基于我将进行的解释，我认为只有第三个选择才是唯一正确地选择。Vinum
需要进行调整以具备和GEOM协同工作的能力，至少在那些功能互相重叠的领域。
我的一个问题在于如何理解GEOM和Vinum之间的关系。是的，我们可以轻易的了解到
以下的状态（来自于geom(4)）：
在固定的架构上是不可能镜像两块物理磁盘并且将分区镜像到子磁盘上去，
替代的方法之一是强制在物理卷上建立子磁盘并且镜像这两个分区结果造成
更多复杂的配置。而GEOM就不必上述的问题。
非常显然GEOM在这个领域具备显著的优势（但是同时也会有更多的机会使得用户
射中自己的脚(古怪的比喻)；对上述的说明是“唯一的限制就是图示中的方法并不
被允许。”）我的问题是：它还能提供什么优势？我正在为下星期在阿德莱得举行的
Linux.Conf.Au大会（http://lca2004.linux.org.au/如果你有兴趣，这篇论文正是
关于Vinum的论文。）要进行的演讲准备论文，并且我已经提出了下列关于Vinum特点
的列表：
－通过vinum工具程序在线进行配置。
－自动错误检测并且在可能的情况下进行恢复。
－每个对象的状态信息。这个使得即使一些对象不能访问的时候Vinum的功能也能保持正常。
－持续的配置。每个Vinum驱动器存储两份配置的拷贝，使得系统能够自动的启动。
这个配置包括状态信息，使得任何降级的对象在重启完毕之后都保留下来，或者
甚至是移动到一个全新系统上去。
－支持在Vinum上建立根文件系统。
－在线重建对象。
非常有趣的是，这些方面都是GEOM不会涉及的，至少在我看来。我是否还落了什么吗？
基于这种理解，我的意图是Vinum当前不应该去覆盖下列东西：
－使用相应的GEOM覆盖对象卷，丛和子磁盘。我希望能够采取更加专断的方法
来结合对象，但是这就涉及了所有方面。
－使用gctl_s覆盖ioctls。这看起来更有装饰性而不是功能性，虽然也是个好主意。
这些将会是很有价值的，但是我还是希望能有更多的努力。还有那位能够提出更多的
有益的意见？