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