到目前为止，ownCloud 用户只能在基于 POSIX 兼容文件系统的简单本地文件存储或 EOS Open Storage (EOS) 之间进行选择。后者在设置过程中会导致巨大的复杂性。最近版本的 ownCloud 具有一个名为 Decomposed FS 的功能。此文件系统旨在将 oCIS 带到任意存储后端，甚至是可扩展的后端。
在将 ownCloud 从 PHP 重写为 Go 的过程中，私有云解决方案背后的公司正在对软件的后端进行重大更改。这一次，开发人员取消了早期版本的 ownCloud Infinite Scale (oCIS) 的繁琐要求。通过实现文件系统抽象层，oCIS 可以使用任意后端存储（甚至可以使用可以无缝扩展的存储机制）。本文解释了 ownCloud 做出此决定的原因、Decomposed FS 组件背后的细节，以及这对 ownCloud 用户和未来部署意味着什么。
要理解 oCIS 面临的困境，重要的是回顾一下 ownCloud Infinite Scale 的发展历程。最初试图获得更高性能的尝试导致了使用与之前不同的编程语言对工具进行完全重写。然而，ownCloud 在重写其核心产品时与多家公司和机构合作。在与 ownCloud 合作的组织中，有一所澳大利亚的大学。该大学使用 EOS，这是一种由欧洲物理研究机构 CERN 开发的存储技术，CERN 因运行诸如大型强子对撞机 (LHC) 等项目而闻名。为了使 ownCloud 和澳大利亚大学之间的合作有意义，oCIS 需要与该研究所现有的本地存储解决方案相关联。
CERN 的文件存储与普通用户通常使用的文件存储截然不同。虽然 LHC 不是 CERN 唯一的实验，但它无疑属于产生最大量数据的实验之一。尽管 CERN 使用诸如 OpenStack 之类的技术来处理来自活跃 LHC 的数据，但每天仍需要将 TB 级的数据保存到某个地方以供以后使用。因此，CERN 在其自身存储解决方案方面最重要的因素之一是无缝的可扩展性。该研究所对这一需求的回答是一种名为“EOS Open Storage”(EOS) 的存储解决方案。在撰写本文时，CERN 的 EOS 容量超过 500 PB，使其成为全球实验机构中使用最广泛的存储设施之一。
EOS 不是文件系统，甚至与文件系统都不接近。相反，它是具有各种接口的众多服务的组合。它隐式地处理冗余，并且其布局可能会使一些读者想起诸如 LustreFS 之类的解决方案，具有用于文件元数据和文件放置的中心服务。EOS 显然是为海量数据而设计的。它具有扩展到普通管理员几乎不会遇到的维度的能力。
EOS 不适用于最终用户
正是这种巨大的规模很快使 oCIS 和 EOS 之间的紧密联系成为供应商及其软件面临的挑战。问题来了，是否也可以像 ownCloud 10 一样，使用简单的本地存储驱动程序运行 oCIS？该基本驱动程序没有提供 ownCloud 想要实现的所有功能。另一方面，即使是最乐观的 oCIS 开发人员从一开始就知道，普通最终用户肯定不会运行他们自己的 EOS 实例。这有几个原因。首先，所需的硬件对于管理员来说没有意义，并且很可能超过预算几个数量级。此外，仅为了存储萨莉阿姨生日派对的照片而运行诸如 EOS 之类的存储解决方案也没有多大意义。事实上，EOS 的复杂性很快就会让大多数用户远离 oCIS。为了使 oCIS 即使对于普通用户也能获得成功，ownCloud 必须制定一个适合在较小环境中通常找到的存储设施的计划。这就是 Decomposed FS 发挥作用的地方。
存储文件面临的挑战
为了理解 Decomposed FS 实际上是什么，有必要记住典型的 POSIX 文件系统是如何工作的，以及为什么这对诸如 oCIS 之类的解决方案可能是一个挑战。文件系统是一种允许使用任意存储设备的数据结构。通常，基于存储块的设备（块设备）用于此任务。如果没有文件系统，则可以将文件写入设备，但无法在稍后的时间点以有针对性的方式读取文件。相反，需要遍历存储设备的整个内容，直到找到特定信息，这当然效率很低并且速度很慢。
如今，UNIX 和类 UNIX 文件系统大多使用满足 POSIX 文件系统标准要求的文件系统（图 1）。因此，它们使用基于层次结构的结构，这就是为什么您经常读到“文件系统树”的原因。因此，通常会有一个根目录 (/) 和包含实际文件及其有效负载的子目录。严格来说，目录在文件系统内部被视为一种特殊类型的文件。文件访问是基于路径的。用户将隐式或显式地指定他们想要打开的文件的完整路径，并且相应的内核文件系统驱动程序从存储设备读取该文件并将其呈现给用户。这个过程本身已经是一个复杂的机制。
图 1：POSIX 兼容的文件系统允许用户仅根据其路径访问文件。这很慢，并且阻止了几个相关功能的正确实现（Markus Feilner 和 Martin Loschwitz，CC BY-SA 4.0）。
但情况变得更糟。在现代操作系统中，路径不是文件的唯一属性。例如，考虑文件权限。限制特定人员对特定文件的访问是可取的。想象一下一个邮件服务器，用户只有在使用用户名和密码成功登录后才能访问他们的邮箱。管理员绝对不希望用户 A 能够打开用户 B 的邮箱。为了满足这种需求，文件系统实现了一种权限方案。对于文件系统中的每个任意文件，必须将允许访问它的人员的信息存储在某个地方。这就是 inodes 在基于 POSIX 的文件系统中发挥作用的地方。 Inode 存储所谓的文件元数据，并且文件系统将一个 ID 与存储设备上文件的实际路径相关联。用户无法通过 inode-id 访问 Inode 和关联的文件。此外，inode 使用可回收的 ID，这意味着与一周前的情况相比，某个 inode ID 可能包含另一个文件的元数据。
“直接使用它！” 对 oCIS 来说是不够的
坏消息还没有结束。如上文所述，根本无法通过静态 ID 访问 POSIX 文件系统上的文件。传统的 POSIX 方案只允许基于路径的访问。当然，特定文件系统的内核驱动程序将在内部基于 inode 的 ID 执行 inode 查找 - 但该 ID 对于用户来说不是唯一的和不透明的。
听起来像是技术上的细微差别，但对于诸如 ownCloud Infinite Scale 之类的解决方案来说，这是一个主要的破坏因素。 对于它来说，传统的 UNIX 文件处理方式在很多方面都不太合适。当然，以一种仅依赖于底层文件系统的文件处理方式来编程 oCIS 似乎很诱人。这将不可能为不同的存储后端使用不同的驱动程序。 相反，一般的假设是存储后端中 POSIX 原理图的可用性以相同的方式运行。诸如 EOS 之类的解决方案将已经出局，基于 Amazon 的 S3 的解决方案以及诸如 Ceph 及其支持存储 RADOS 对象存储之类的有希望的技术也将如此。那些对 oCIS 和 S3NG oCIS 存储的上游细节感兴趣的人应该 点击这里。
用户想要 POSIX 无法提供的功能
如今，用户通常对诸如 ownCloud 之类的解决方案的期望远远超过了 POSIX 标准的能力。 以一个像回收站一样简单的功能为例。 用户通常希望存储解决方案提供一个回收站，作为在永久删除文件之前临时存储文件的地方。 错误会发生，用户通常很高兴，因为他们可以从他们已经认为丢失的回收站中收集文件。 POSIX 根本不提供类似于回收站的功能。 在典型的 POSIX 文件系统中实现回收站意味着迭代整个树并在文件系统内移动文件。 如果用户将包含数千个文件的目录移动到回收站，这将非常低效，消耗大量资源，并且需要相当长的时间才能完成。
如果到位，内核缓存有助于管理与此类操作相关的性能问题。 但这是一种伪装的毒药。 依赖它会在 oCIS 使用的存储设备上的文件系统驱动程序上添加另一个约束。
从 ownCloud 的角度来看，在文件系统上移动文件甚至没有意义。 毕竟，ownCloud 只需要知道某些文件被标记为“已删除”，实际数据位于物理存储设备上的哪个位置并不重要。
元数据：从 oCIS 的角度来看，“这里有恶龙”
同样，由于前面提到的原因，直接通过 inode-ID 编辑 inode 中的元数据是不可能的。 从另一个角度来看，这是有问题的：对于诸如 ownCloud 之类的解决方案来说，高效地附加其他元数据具有挑战性。 现代文件系统支持用户扩展属性，这是一组任意属性，可以在系统的用户环境中定义。 因为没有安全的方法来可靠地访问树中任何给定文件的元数据而不遍历它，所以理论上可用的功能在很大程度上仍然未使用。
长话短说：传统的 POSIX 语义对于像 oCIS 这样的解决方案带来了一些问题。两个主要问题是无法通过唯一 ID 访问文件，以及无法在不遍历整个文件系统树的情况下访问文件元数据。
oCIS 开发者现在称之为“分解式文件系统”（Decomposed FS）是他们试图将 ownCloud 自身的的文件处理与底层存储设备上的文件处理分离的尝试。分解式文件系统之所以得名，是因为该功能部分地在任意存储设施之上实现了 POSIX 文件系统的某些方面。与现有解决方案形成鲜明对比的是，分解式文件系统中的一切都围绕着基于唯一 ID（更准确地说，是 UUID）的文件访问概念（图 2）。
图 2：分解式文件系统的第一个版本使用唯一 ID (UUID) 来命名文件。此外，还建立了一个符号链接结构，以允许通过遍历文件树进行访问 (Markus Feilner 和 Martin Loschwitz, CC BY-SA 4.0)
这在实践中如何运作？
像普通的 POSIX 文件系统一样，分解式文件系统使用分层模型来处理其文件。一个根目录甚至充当访问存储在 ownCloud 中的所有文件的入口。oCIS 将在根目录下的文件系统层上创建具有唯一 ID（UUID）作为名称的单独文件。在这些文件中，将存在文件的实际有效负载（blob）。
现在很明显，ownCloud 仍然需要一种方法来从用户的角度组织目录中的文件。用户仍然会认为他们可以为自己的文件实现一个分层结构（“Pictures / Holidays / Bahamas 2021 / ...”），而无需考虑软件如何在内部组织其文件。为了模仿这种结构，ownCloud 开发者求助于符号链接。他们创建了一个单独的树，其中包含代表用户可见树的文件和文件夹的“节点”。文件元数据存储在该节点的扩展属性中。这确保了通过简单地遍历它们（更准确地说，是符号链接树）来访问文件仍然是可能的，同时也可以直接基于其唯一 ID 访问单个文件。另一个优点是，迭代树只需要加载不包含文件内容的节点。只有当用户下载文件时，才会加载文件内容。即使在树中移动文件也不再触及文件内容；它只是更改节点树。
图 3：底层文件系统不提供诸如回收站之类的功能，它们需要由软件提供，而分解式文件系统使之变得更加容易且资源消耗更少（Markus Feilner 和 Martin Loschwitz, CC BY-SA 4.0）。
当查看先前将许多文件移动到回收站的示例时（图 3），这种操作模式带来了巨大的优势。当分解式文件系统将文件移动到回收站时，它不是在后端存储上移动实际文件，而是使 oCIS 将 *inodes* 标记为“已回收”，而不是实际文件。
这是一个基本的技术解释。在分解式文件系统中，我们只创建、创建符号链接和移动，这些都是 POSIX 上的原子操作。此外，我们在更改文件属性时实现锁定以避免冲突。
oCIS 开发者在创建分解式文件系统时考虑的一个因素是尽可能与底层存储设备无关。目前，任何给定的 POSIX 文件系统都可以。用户的家目录不会被触及。所有 blob 和节点都存储在 ocis 数据目录中。
也就是说，可以安全地假设 oCIS 将在当前 Linux 或 Windows 支持的几乎每个文件系统之上可靠地工作。它肯定会与广泛的文件系统配合使用，这些文件系统用作这些操作系统的标准文件系统。
未来的道路
oCIS 人员明确将分解式文件系统称为“未来开发的试验台”。出乎意料的是，ownCloud Infinite Scale 的 oCIS 文件系统驱动程序已经实现了 ownCloud 记录的大部分分解式文件系统设计组件。开发人员的想法层出不穷，不断改进这个概念。唯一控制由 ownCloud 创建的分解式文件系统实例的是 ownCloud 本身。供应商可以自由地尝试和扩展分解式文件系统功能集。
因此，新的功能会定期添加到分解式文件系统，例如能够将分解式文件系统命名空间与 oCIS 中存储在文件中的数据的实际有效负载完全分离。该功能已经应用到了 oCIS 存储驱动程序的一个扩展中，该扩展以 Amazon S3 协议命名，因为它支持在单独且不同的存储设备上存储文件，甚至是在本地不存在的设备上。仅存储文件内容的本地 blobstore 可以被远程对象存储替换。这就是 S3 在设置中首次亮相的地方。如果只需要在本地存储元数据，而 S3 是支持存储，那么实际上，用户已经配备了无缝且无限可扩展的存储。
oCIS 及其更快、更灵活的 oCIS 驱动程序，尚不足以让供应商安于现状。该驱动程序已经计划了新的功能，其中包括由 ownCloud 人员设计的一个功能，可谓是令人叹为观止。在未来的版本中，ownCloud 计划取消在 POSIX 兼容后端上存储文件的要求。
为了理解为什么这有意义，再次了解 POSIX 会有所帮助。POSIX 的设计旨在在访问文件系统时提供各种保证。这些保证包括在重命名文件和覆盖现有文件时对读取和写入的一致性保证。然而，许多这些操作甚至不会在 ownCloud 设置中发生。由于 ownCloud 在存储后端维护自己的文件系统，因此覆盖文件并不意味着用较新的内容替换存储设备上的内容。相反，会添加一个新的 blob，并且现有符号链接会更改为指向新文件。如果 POSIX 保证不消耗本来可供用户使用的性能，那么它们就不会成为问题。
ownCloud 人员并非第一个遇到此问题的人。可扩展对象存储 RADOS（Ceph 的核心）的开发人员长期以来一直使用 XFS 作为磁盘格式，然后放弃它并创建了 BlueStore（图 4）。BlueStore 消除了在物理存储设备上拥有 POSIX 文件系统的需求。相反，Ceph 只是将对象的名称和物理存储地址存储在一个基于 RocksDB 的巨大键值存储中。ownCloud 已经表达了将分解式文件系统朝类似方向发展的意图。在这种设置中，不再需要本地文件系统。相反，有关现有文件及其路径的详细信息也存储在大型 RocksDB 键值存储中。甚至在这种环境中也消除了对本地符号链接树进行迭代的需求。
图 4：Ceph 长期以来一直放弃使用 POSIX 作为其磁盘文件方案。相反，它求助于 RocksDB 和一个最小化的自行编写的文件系统。ownCloud 的分解式文件系统架构很快将允许它效仿（Markus Feilner 和 Martin Loschwitz, CC BY-SA 4.0）。
此外，与简单的 POSIX 兼容文件系统相比，oCIS 维护自己的文件系统命名空间带来了几个主要的优势，并将允许实现其他功能。例如，ownCloud 可以以类似于 Git 的方式处理其文件，其中存在同一文件的不同版本。通过键值存储实现访问，可以轻松存储有关同一文件先前版本的信息。
总结：面向大众的 oCIS
从 oCIS 的角度来看，分解式文件系统的引入以及将实际文件存储与文件系统元数据分离的能力是巨大的改变游戏规则者。许多家庭用户可能仍然使用单个磁盘作为本地 oCIS 存储后端，并简单地受益于分解式文件系统带来的性能提升。与此形成鲜明对比的是，机构和公司会喜欢由于这项新功能，在可扩展存储解决方案中运行 oCIS 已经变得容易得多。如果未来要实施的其他改进措施进入稳定的 oCIS 发行版，将会进一步提高 oCIS 的多功能性。一个将文件 blob 直接写入 Ceph 的 ownCloud 实例对于 SMB 来说可能非常有趣——毕竟，即使是构建小型 Ceph 集群也已经一去不复返了。无论如何，分解式文件系统的开发加强了 oCIS 并使其可供更广泛的受众使用。
1 条评论