采访：让Samba超出POSIX

　　developerWorks 就 Tridge 在 IBM 的工作、Samba 3.0 的状态以及他对 smbd 重写的看法与之进行了交谈。

　　如果您有幸参加过在德国哥廷根（G(o)ttingen）举行的 Samba 体验（Samba eXPerience）大会，您可能听到过 Samba 创始人 Andrew Tridgell 就“外来文件系统后端（Exotic Filesystem Backend）”发表的演讲（参阅 参考资料以获取到 Samba 体验主页的链接）。

　　Tridge 就外来文件系统后端确切地必须说些什么呢？实际情况是，自从今年 1 月受雇于 IBM 阿尔马登研究中心（Almaden Research Center，参阅 参考资料以获取阿尔马登实验室页面的链接）以来，这位澳大利亚黑客就一直致力于使 Samba 超出 POSIX 领域，还致力于确定要使 Samba 支持诸如 XFS、ext3 和 Storage Tank 之类的新文件系统，需要做什么工作。结论是彻底重写 Samba 的 smbd 代码，这已成为他的“新宠”项目。

　　developerWorks：您在 IBM 从事哪种工作？

　　Tridgell：我并不只是作为一名 Samba 技术人员受雇于 IBM 的。实际上，我加盟的是阿尔马登研究实验室（Almaden Research Labs），该实验室正在进行一些比起即将推出的产品来略具前瞻性的工作。我的工作内容不囿于 Samba 这方面的事情，虽然我目前暂时所从事的特定研究项目是一个与网络连接的存储器项目，在该项目中，我们正在研究下一代 NAS 解决方案，并正在将该项目同 IBM 正在开发的某些外来文件系统进行集成。这是一项十分有趣的工作，它使我有机会从事周期比较长的工作。当我在 Quantum 和 VA [Tridgell 以前干过的两家公司 — 编者。]，我常常超越 Samba 核心结构的限制。为了在三个月或四个月这类时间段之内交付产品，我们确实不得不绕开这些核心限制，这意味着我们不得不做些粗劣的折衷，尤其是在 NT 访问控制表（Access Control List，ACL）方面以及缺少对诸如文件流之类的事务的支持时，或者在用户和组管理方面做些折衷。这些只是注重实效的折衷，因为我们没有那个实力真的说：“好，让我们重写整个 Samba 吧”。

　　在研究机构中，我的眼光可以放得更长远一些，我可以研究在接下来的一两年内究竟要做哪些工作，并且指出：“我们想把下一代 Samba 带向何方？”以及“如果我们想正确地解决这些问题，那么它看起来应该象什么样子？”。我可以认真地解决这些问题。实际上，目前我所进行的许多工作都受到了我为 VA 和 Quantum 开发产品期间所碰到问题的启发。因此，其它一些生产 NAS 产品的公司最终也将从这一工作中受益。

　　dW：您是否正在讨论 Samba 4.0 类型的问题？

　　Tridgell：暂时，可能会纳入 4.0。也可能会纳入 3.1 或 3.5。这确实取决于其进展情况。目前，这项工作确实只是处于早期阶段。到目前为止，我在内核重写上大概花了一个月的时间。编译到现在还没进行。离编译还有很长的一段路。我希望，到 Samba 经验大会在德国举行的时候，这些核心更改能够进行实际的编译，从而我能够着手让别的开发人员研究它们。至此，我所做的全部工作只是启动了核心结构更改。我已经在 Samba 团队内演示了这些更改，并得到了其他 Samba 核心开发人员的赞同，他们说他们欣赏这些想法。至此，所有人对它们都很热心。

　　dW：您能告诉我有哪些更改吗？

　　Tridgell：历史上，Samba 是一个到 POSIX 的网关。它提供对类 POSIX 系统的访问。这一点十分有用，因为很多人在他们的服务器上安装了类 POSIX 系统 — 如 Linux、Solaris、AIX 及其它系统 — 而为这些 POSIX 服务器提供优质 CIFS [公共因特网文件系统，Common Internet File System] 访问显得十分有用。但 POSIX 在某些方面具有相当的局限性。有些东西很难从 Windows 世界映射到 POSIX 世界。典型的例子是称为文件流的东西。在 Windows 世界中，文件可以拥有多个与之相关的数据集。但是，在 POSIX 世界中，文件只有一个与之相关的数据流。您可以将文件中的字节从 0 编到 N，而在 Windows 中则允许进行二维类型的访问。

　　现在，我们已经好久没有在 Samba 中支持文件流了，能这样做而不出错很侥幸，这基本上是因为 Windows 上的几乎所有应用程序都确实支持没有文件流的服务器，因为旧式 Windows 服务器（如 Windows 9x）不支持文件流。因此，应用程序往往可以支持带有或不带有文件流的系统。Microsoft Office 在 Samba 服务器上存储其文件的方式与它在 Windows 2000 服务器上存储的方式略有不同。但是，随着时间的推移，这一点将会改变。例如，如果 Office 将来的版本开始需要文件流，我不会感到吃惊。如果更多应用程序开始依赖类似这样的特性，我也不会吃惊。

　　因此，我们需要能够终止与 POSIX 的紧密联系，并能够直接在 Samba 中支持 Linux 上现在可用的比较高级的文件系统，如 JFS 和 XFS。正在为 Linux 开发的有趣的文件系统有很多，它们所具备的功能远远超出了核心文件系统 POSIX 规范中所定义的内容。我们希望能在 Samba 内利用这些文件系统。

　　dW：那么，您现在正在着重研究哪些文件系统？

　　Tridgell：Storage Tank 文件系统（参阅 参考资料以获取链接）是我正在着重研究的一个文件系统，它是一种基于 SAN 的文件系统。

　　但我目前正在做的初始工作并不是特定于 Storage Tank 的。它是非常具有普遍性的工作。我针对的第一个文件系统后端是一种极不平凡的文件系统：它是一种 CIFS 后端。因此，您将拥有一个 Samba 服务器，它与另一个 SMB [服务器消息块，Server Message Block] 服务器（如另一个 Samba 或 Windows 服务器）进行通信，而 Samba 的核心实际上将对作为其后端的另一个 SMB 服务器使用远程文件访问。我们从没有期待任何人在生产系统中这么做。很难想象这样一种情形：您想拥有这种“CIFS 上的 CIFS 网关”，但 CIFS 后端确实为在 Samba 中开发外来文件系统后端的核心功能提供了一个理想的实验床，因为 Windows 2000 后端拥有我们可能想要的所有功能，因为它拥有 CIFS 支持的全部功能，因为它 是CIFS。因此，例如，它支持本机 NT ACL，因为它 是本机 NT。

　　因此，通过在 Samba 中将这种后端用作试验性文件系统后端，我们可以开发支持所有这些扩展所需的核心结构。一旦将它提供给不算太“外部”的文件系统，如 ext3、XFS 或 Storage Tank，那么它们将有一个可用的功能子集，但我们知道核心结构将正常运行。如果您愿意，我们将拥有一个完美的后端。

　　dW：Microsoft 一直在谈论对其文件系统做一些根本的修改 — 例如，创建一个面向数据库的文件系统，如对象文件系统（Object File System）。如果 Microsoft 彻底更改了其文件系统，您期望 Samba 项目会得到发展以支持这一变化吗？

　　Tridgell：作为 Samba 项目的题外话，我希望 Samba 最终会消失，因为我们希望最终将不再需要它。但严格来说这确实只是个玩笑。很长一段时间以来，都存在着这样一种可能性：Microsoft 将转向一种不同的网络文件系统协议。例如，有些人认为 WebDAV 可能会成为这一协议，Web 将成为文件系统。这作为一种可能性好像已经不复存在了；它完全不具备 Microsoft 应用程序想要的丰富功能。

　　我并没有真正地参加过有关这个文件系统的数据库替代品的讨论。此时出现显得极其冒险。如果 Microsoft 在某个时候改变其核心文件系统协议，我也不会感到吃惊，因为这些协议随同 CIFS/SMB 协议一起还包括了很多过去遗留下来的“负担”。其中有大量的内容对于现代平台没有意义，但还得继续带上它们，因为这是它们从自身或别处继承来的核心协议的一部分。因此，从零开始肯定是非常有吸引力的，不过话又说回来，这么做对于他们而言将是一项巨大的工程。而且，我们还没有看到任何显示这项工作即将开始的迹象。但话说回来，可能是我们没有看到。我们并不在 Microsoft 内部有关这种讨论的 CC 列表上面。

　　dW：您认为您正在进行的某些研究将会具有超过 CIFS 的应用吗？

　　Tridgell：Samba 本身已经略微超出了 CIFS 的范围。当人们根本不想要文件和打印服务时，他们就安装 Samba 组件。例如，我们看到公司安装 Winbind 守护程序，它是一个较新的、提供域集成的 Samba 组件 — 允许您的 Linux 桌面与现有的 Microsoft 域集成，而完全不提供任何文件或打印服务。这是正在不断发展的 Samba 用法。因此，实际上 Samba 的角色已经不限于文件和打印。

　　如果新的协议出现，Samba 团队会开始进行有关该协议的工作吗？嗯，这确实取决于该协议与我们现有的工作联系有多紧密，以及我们进行这些工作是否合适。例如，当活动目录（Active Directory）出现时，它与现有的 MS-RPC 协议以及现有的域基础结构联系得非常紧密。因此，很显然这是 Samba 团队应该处理的问题，而且在过去的大约 18 个月中我们确实已经处理了这一问题，而且工作得非常、非常顺利。

　　但 Microsoft 也已涉足了 NFSv4 这一领域，虽然 NFSv4 与 CIFS 和 SMB 拥有许多共同概念，但它却没有分享足够多的共同技术细节，没有任何公共代码，因此 Samba 团队除了作为感兴趣的旁观者之外完全不会参与进去。

　　dW：您说过：前几年从事 NAS 项目期间您学到了很多东西。在解决 Samba 的过程中，你们正在研究解决的最大问题是什么？

　　Tridgell：Samba 正在设法解决的普遍性问题是语义映射问题，它设法将 POSIX 的语义映射到 CIFS 协议上去。因此，Samba 由许多提供这一映射的小组件组成。典型的示例是将区分大小写映射成不区分大小写。Windows 期望的是不区分大小写的服务器，而 POSIX 系统传统上是区分大小写的。

　　从区分大小写映射到不区分大小写现在看来是很微不足道的，但实际上很难有效地进行这一映射。给定一个文件名，要证明该文件不存在很难很难。如果该文件确实存在，那么您可以就其区分大小写的名称到底是什么进行很好的猜测。实际上，大多数时候，它只是那个通过线路从客户机发送过来的原样的字符串。但是，要在 POSIX 上证明某个文件绝对没有以任何大小写组合的形式出现，这所付出的代价十分昂贵。现在，POSIX 系统没有任何吸引人的方法来说：“请以不区分大小写的方式来执行这个 open ”，这样，在 Samba 中，我们就有了各种基础结构来提供从区分大小写到不区分大小写的映射。但这种基础结构深深地嵌入到了 Samba 代码的各个部分。

　　这些日子，我们真正开始看到 Linux 和其它 UNIX 上出现了具有非 POSIX 语义能力的文件系统。例如，它们可能拥有一些方法，可以要求文件系统：“请以不区分大小写的方式进行操作”。我们需要指示 Samba：所有这些工作它现在都没有必要做了，因为文件系统将完成这些工作 — 而且效率比起 Samba 可能在用户空间进行的处理的效率要高得多。但从 Samba 除去所有这些代码是十分主要的工作。因此，我意识到：为了做到这一点，我们需要重新构建 Samba 的结构，使之更模块化，这种结构允许在不付出 POSIX 映射代价的情况下就可以使用同 POSIX 完全分离的后端。这确实就是我目前试图进行重写的核心。

　　dW：这听起来象是一个全新的 Samba 体系结构。

　　Tridgell：这是一项重大的更改。它确实只改变了核心 smbd 功能。例如，它没有改变 MS-RPC 代码中的域功能，也没有改变我们的用户及组映射代码。因此，它仅仅影响始终属于 Samba 核心的那一部分，但是照我大致猜测来看，这一部分现在可能占 Samba 代码的 30%。不过，在这 30% 的代码上所进行的重写却是十分有意义的。

　　dW：我还想问你的是，Samba 3.0 的最新情况如何。我想，自 2001 年 11 月 以来，它就一直处于 alpha 测试阶段。

　　Tridgell：它处于 alpha 测试阶段已有很长很长的时间了。实际上，从某种意义来说，alpha 这个说法并不恰当，因为实际上很多公司正在将其用于生产。我知道的供应商中至少有两个正在其工具的产品代码里包含了 Samba 3.0。它正在被相当广泛地部署。我们原希望到今年举行 Samba XP 大会时，最终发行版已经完成，但实际上并没有完成。仍然有一些文档需要编制，也还有一些 QA 工作需要完成，但代码状态确实非常好。对于某些用途，它要比我们的稳定发行版好得多，因为它可以从这些正在生产中使用的公司得到大量的 QA。特别是当我在 Quantum 工作的时候，它们有一个非常优秀的 QA 部门，这个团队为使 3.0 代码库能够稳定地作为文件服务器，投入了大量的工作。尤其是在很大的域，或在很高的负载下，更是如此。这项工作意味着 Samba 3.0 实际上比人们可能对 alpha 测试版代码的期望要稳定得多。

　　dW：那么，大型域和高负载就是人们最感兴趣的 Samba 3.0 能处理的情形？

　　Tridgell：对。或者说，例如，如果您需要活动目录支持时。有许多公司需要活动目录，因为它们的基础结构是围绕活动目录模型而建的。在这种情形下，3.0 是您唯一的选择。它是唯一一个支持 Kerberos 认证和带有活动目录服务器的 LDAP（此类东西）的后端。而且，它还是一种更为灵活的认证系统。如果您需要复杂的认证后端，那么您的确需要 Samba 3.0，而且 3.0 拥有好得多的字符集处理功能来进行国际化。现在，它在线路上使用 Unicode 而不是多字节编码与 Microsoft 客户机通信。这允许它以清楚得多、好得多的方式支持非 ASCII 字符集。

　　dW：那么，3.0 在哪些方面的行为确实象 alpha 测试版代码呢？谁不想使用它呢？

　　Tridgell：文档编制工作还没有真正完成。管理工具还有点粗糙。还有一些类似的事情也没有完全完成。假设我进行发布，那么我可能已经将其作为 3.0 发布了。几年前，当我还是发布经理的时候，我的发布工作常常要比他们快得多。每个发布经理往往有他们自己的风格... Jeremy [Allison] 是前任发布经理，而 Jerry [Carter] 在几个月前刚刚接替了他。Jerry 和 Jeremy 倾向于更保守一些，这可能是件好事。