Stratis是一个卷管理文件系统volume-managingfilesystem（VMF），类似于ZFS和Btrfs。它使用了存储“池”的核心思想，该思想被各种VMF和形如LVM的独立卷管理器采用。使用一个或多个硬盘（或分区）创建存储池，然后在存储池中创建卷volume。与使用fdisk或GParted执行的传统硬盘分区不同，存储池中的卷分布无需用户指定。
VMF更进一步与文件系统层结合起来。用户无需在卷上部署选取的文件系统，因为文件系统和卷已经被合并在一起，成为一个概念上的文件树（ZFS称之为数据集dataset，Brtfs称之为子卷subvolume，Stratis称之为文件系统），文件数据位于存储池中，但文件大小仅受存储池整体容量限制。
换一个角度来看：正如文件系统对其中单个文件的真实存储块的实际位置做了一层抽象abstract，而VMF对存储池中单个文件系统的真实存储块的实际位置做了一层抽象。
基于存储池，我们可以启用其它有用的特性。特性中的一部分理所当然地来自典型的VMF实现implementation，例如文件系统快照，毕竟存储池中的多个文件系统可以共享物理数据块physicaldatablock；冗余redundancy，分层，完整性integrity等其它特性也很符合逻辑，因为存储池是操作系统中管理所有文件系统上述特性的重要场所。
上述结果表明，相比独立的卷管理器和文件系统层，VMF的搭建和管理更简单，启用高级存储特性也更容易。
简单可靠地使用高级存储特性Stratis希望让如下三件事变得更加容易：存储初始化配置；后续变更；使用高级存储特性，包括快照snapshots、精简配置thinprovisioning，甚至分层tiering。
Stratis与ZFS和Btrfs有哪些不同？作为新项目，Stratis可以从已有项目中吸取经验，我们将在第二部分深入介绍Stratis采用了ZFS、Brtfs和LVM的哪些设计。总结一下，Stratis与其不同之处来自于对功能特性支持的观察，来自于个人使用及计算机自动化运行方式的改变，以及来自于底层硬件的改变。
首先，Stratis强调易用性和安全性。对个人用户而言，这很重要，毕竟他们与Stratis交互的时间间隔可能很长。如果交互不那么友好，尤其是有丢数据的可能性，大部分人宁愿放弃使用新特性，继续使用功能比较基础的文件系统。
第二，当前API和DevOps式Devops-style自动化的重要性远高于早些年。Stratis提供了支持自动化的一流API，这样人们可以直接通过自动化工具使用Stratis。
第三，SSD的容量和市场份额都已经显著提升。早期的文件系统中很多代码用于优化机械介质访问速度慢的问题，但对于基于闪存的介质，这些优化变得不那么重要。即使当存储池过大而不适合使用SSD的情况，仍可以考虑使用SSD充当缓存层cachingtier，可以提供不错的性能提升。考虑到SSD的优良性能，Stratis主要聚焦存储池设计方面的灵活性flexibility和可靠性reliability。
最后，与ZFS和Btrfs相比，Stratis具有明显不一样的实现模型implementationmodel（我会在第二部分进一步分析）。这意味着对Stratis而言，虽然一些功能较难实现，但一些功能较容易实现。这也加快了Stratis的开发进度。
评论