在 Linux 中使用 Stratis 配置本地存储
Stratis 存储

> 
> 关注于易用性，Stratis 为桌面用户提供了一套强力的高级存储功能。
> 
> 
> 


![](/data/attachment/album/201806/11/115418aq0e85ss081523sn.jpg)


对桌面 Linux 用户而言，极少或仅在安装系统时配置本地存储。Linux 存储技术进展比较慢，以至于 20 年前的很多存储工具仍在今天广泛使用。但从那之后，存储技术已经提升了不少，我们为何不享受新特性带来的好处呢？


本文介绍 Startis，这是一个新项目，试图让所有 Linux 用户从存储技术进步中受益，适用场景可以是仅有一块 SSD 的单台笔记本，也可以是包含上百块硬盘的存储阵列。Linux 支持新特性，但由于缺乏易于使用的解决方案，使其没有被广泛采用。Stratis 的目标就是让 Linux 的高级存储特性更加可用。


### 简单可靠地使用高级存储特性


Stratis 希望让如下三件事变得更加容易：存储初始化配置；后续变更；使用高级存储特性，包括<ruby> 快照 <rt>  snapshots </rt></ruby>、<ruby> 精简配置 <rt>  thin provisioning </rt></ruby>，甚至<ruby> 分层 <rt>  tiering </rt></ruby>。


### Stratis：一个卷管理文件系统


Stratis 是一个<ruby> 卷管理文件系统 <rt>  volume-managing filesystem </rt></ruby>（VMF），类似于 [ZFS](https://en.wikipedia.org/wiki/ZFS) 和 [Btrfs](https://en.wikipedia.org/wiki/Btrfs)。它使用了存储“池”的核心思想，该思想被各种 VMF 和 形如 [LVM](https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)) 的独立卷管理器采用。使用一个或多个硬盘（或分区）创建存储池，然后在存储池中创建<ruby> 卷 <rt>  volume </rt></ruby>。与使用 [fdisk](https://en.wikipedia.org/wiki/Fdisk) 或 [GParted](https://gparted.org/) 执行的传统硬盘分区不同，存储池中的卷分布无需用户指定。


VMF 更进一步与文件系统层结合起来。用户无需在卷上部署选取的文件系统，因为文件系统和卷已经被合并在一起，成为一个概念上的文件树（ZFS 称之为<ruby> 数据集 <rt>  dataset </rt></ruby>，Brtfs 称之为<ruby> 子卷 <rt>  subvolume </rt></ruby>，Stratis 称之为文件系统），文件数据位于存储池中，但文件大小仅受存储池整体容量限制。


换一个角度来看：正如文件系统对其中单个文件的真实存储块的实际位置做了一层<ruby> 抽象 <rt>  abstract </rt></ruby>，而 VMF 对存储池中单个文件系统的真实存储块的实际位置做了一层抽象。


基于存储池，我们可以启用其它有用的特性。特性中的一部分理所当然地来自典型的 VMF <ruby> 实现 <rt>  implementation </rt></ruby>，例如文件系统快照，毕竟存储池中的多个文件系统可以共享<ruby> 物理数据块 <rt>  physical data block </rt></ruby>；<ruby> 冗余 <rt>  redundancy </rt></ruby>，分层，<ruby> 完整性 <rt>  integrity </rt></ruby>等其它特性也很符合逻辑，因为存储池是操作系统中管理所有文件系统上述特性的重要场所。


上述结果表明，相比独立的卷管理器和文件系统层，VMF 的搭建和管理更简单，启用高级存储特性也更容易。


### Stratis 与 ZFS 和 Btrfs 有哪些不同？


作为新项目，Stratis 可以从已有项目中吸取经验，我们将在[第二部分](https://opensource.com/article/18/4/stratis-lessons-learned)深入介绍 Stratis 采用了 ZFS、Brtfs 和 LVM 的哪些设计。总结一下，Stratis 与其不同之处来自于对功能特性支持的观察，来自于个人使用及计算机自动化运行方式的改变，以及来自于底层硬件的改变。


首先，Stratis 强调易用性和安全性。对个人用户而言，这很重要，毕竟他们与 Stratis 交互的时间间隔可能很长。如果交互不那么友好，尤其是有丢数据的可能性，大部分人宁愿放弃使用新特性，继续使用功能比较基础的文件系统。


第二，当前 API 和 <ruby> DevOps 式 <rt>  Devops-style </rt></ruby>自动化的重要性远高于早些年。Stratis 提供了支持自动化的一流 API，这样人们可以直接通过自动化工具使用 Stratis。


第三，SSD 的容量和市场份额都已经显著提升。早期的文件系统中很多代码用于优化机械介质访问速度慢的问题，但对于基于闪存的介质，这些优化变得不那么重要。即使当存储池过大而不适合使用 SSD 的情况，仍可以考虑使用 SSD 充当<ruby> 缓存层 <rt>  caching tier </rt></ruby>，可以提供不错的性能提升。考虑到 SSD 的优良性能，Stratis 主要聚焦存储池设计方面的<ruby> 灵活性 <rt>  flexibility </rt></ruby>和<ruby> 可靠性 <rt>  reliability </rt></ruby>。


最后，与 ZFS 和 Btrfs 相比，Stratis 具有明显不一样的<ruby> 实现模型 <rt>  implementation model </rt></ruby>（我会在[第二部分](https://opensource.com/article/18/4/stratis-lessons-learned)进一步分析）。这意味着对 Stratis 而言，虽然一些功能较难实现，但一些功能较容易实现。这也加快了 Stratis 的开发进度。


### 了解更多


如果希望更多了解 Stratis，可以查看本系列的[第二部分](https://opensource.com/article/18/4/stratis-lessons-learned)。你还可以在 [Stratis 官网](https://stratis-storage.github.io/) 找到详细的[设计文档](https://stratis-storage.github.io/StratisSoftwareDesign.pdf)。


### 如何参与


如果希望参与开发、测试 Stratis 或给出反馈，请订阅我们的[邮件列表](https://lists.fedoraproject.org/admin/lists/stratis-devel.lists.fedorahosted.org/)。


[GitHub](https://github.com/stratis-storage/) 上的开发项目包括 [守护进程](https://github.com/stratis-storage/stratisd) （使用 [Rust](https://www.rust-lang.org/) 开发）和 [命令行工具](https://github.com/stratis-storage/stratis-cli) （使用 [Python](https://www.python.org/) 开发）两部分。


可以在 [Freenode](https://freenode.net/) IRC 网络的 #stratis-storage 频道加入我们。


Andy Grover 将在今年的 LinuxFest Northwest 会议上演讲。查看[会议安排](https://www.linuxfestnorthwest.org/conferences/lfnw18) 或 [注册参会](https://www.linuxfestnorthwest.org/conferences/lfnw18/register/new)。




---


via: <https://opensource.com/article/18/4/stratis-easy-use-local-storage-management-linux>


作者：[Andy Grover](https://opensource.com/users/agrover) 选题：[lujun9972](https://github.com/lujun9972) 译者：[pinewall](https://github.com/pinewall) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Configuring local storage is something desktop Linux users do very infrequently—maybe only once, during installation. Linux storage tech moves slowly, and many storage tools used 20 years ago are still used regularly today. But some things *have* improved since then. Why aren't people taking advantage of these new capabilities?

This article is about Stratis, a new project that aims to bring storage advances to all Linux users, from the simple laptop single SSD to a hundred-disk array. Linux has the capabilities, but its lack of an easy-to-use solution has hindered widespread adoption. Stratis's goal is to make Linux's advanced storage features accessible.

## Simple, reliable access to advanced storage features

Stratis aims to make three things easier: initial configuration of storage; making later changes; and using advanced storage features like snapshots, thin provisioning, and even tiering.

## Stratis: a volume-managing filesystem


Stratis is a volume-managing filesystem (VMF) like [ZFS](https://en.wikipedia.org/wiki/ZFS) and [Btrfs](https://en.wikipedia.org/wiki/Btrfs). It starts with the central idea of a storage "pool," an idea common to VMFs and also standalone volume managers such as [LVM](https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)). This pool is created from one or more local disks (or partitions), and volumes are created from the pool. Their exact layout is not specified by the user, unlike traditional disk partitioning using [fdisk](https://en.wikipedia.org/wiki/Fdisk) or [GParted](https://gparted.org/).

VMFs take it a step further and integrate the filesystem layer. The user no longer picks a filesystem to put on the volume. The filesystem and volume are merged into a single thing—a conceptual tree of files (which ZFS calls a *dataset*, Btrfs a *subvolume*, and Stratis a *filesystem*) whose data resides in the pool but that has no size limit except for the pool's total size.

Another way of looking at this: Just as a filesystem abstracts the actual location of storage blocks that make up a single file within the filesystem, a VMF abstracts the actual storage blocks of a filesystem within the pool.

The pool enables other useful features. Some of these, like filesystem snapshots, occur naturally from the typical implementation of a VMF, where multiple filesystems can share physical data blocks within the pool. Others, like redundancy, tiering, and integrity, make sense because the pool is a central place to manage these features for all the filesystems on the system.

The result is that a VMF is simpler to set up and manage and easier to enable for advanced storage features than independent volume manager and filesystem layers.

## What makes Stratis different from ZFS or Btrfs?

Stratis is a new project, which gives it the benefit of learning from previous projects. What Stratis learned from ZFS, Btrfs, and LVM will be covered in depth in [Part 2](https://opensource.com/article/18/4/stratis-lessons-learned), but to summarize, the differences in Stratis come from seeing what worked and what didn't work for others, from changes in how people use and automate computers, and changes in the underlying hardware.

First, Stratis focuses on being easy and safe to use. This is important for the individual user, who may go for long stretches of time between interactions with Stratis. If these interactions are unfriendly, especially if there's a possibility of losing data, most people will stick with the basics instead of using new features.

Second, APIs and DevOps-style automation are much more important today than they were even a few years ago. Stratis supports automation by providing a first-class API, so people and software tools alike can use Stratis directly.

Third, SSDs have greatly expanded in capacity as well as market share. Earlier filesystems went to great lengths to optimize for rotational media's slow access times, but flash-based media makes these efforts less important. Even if a pool's data is too big to use SSDs economically for the entire pool, an SSD caching tier is still an option and can give excellent results. Assuming good performance because of SSDs lets Stratis focus its pool design on flexibility and reliability.

Finally, Stratis has a very different implementation model from ZFS and Btrfs (I'll this discuss further in [Part 2](https://opensource.com/article/18/4/stratis-lessons-learned)). This means some things are easier for Stratis, while other things are harder. It also increases Stratis's pace of development.

## Learn more

To learn more about Stratis, check out [Part 2](https://opensource.com/article/18/4/stratis-lessons-learned) of this series. You'll also find a detailed [design document](https://stratis-storage.github.io/StratisSoftwareDesign.pdf) on the [Stratis website](https://stratis-storage.github.io/).

## Get involved

To develop, test, or offer feedback on Stratis, subscribe to our [mailing list](https://lists.fedoraproject.org/admin/lists/stratis-devel.lists.fedorahosted.org/).

Development is on [GitHub](https://github.com/stratis-storage/) for both the [daemon](https://github.com/stratis-storage/stratisd) (written in [Rust](https://www.rust-lang.org/)) and the [command-line tool](https://github.com/stratis-storage/stratis-cli) (written in [Python](https://www.python.org/)).

Join us on the [Freenode](https://freenode.net/) IRC network on channel #stratis-storage.

*Andy Grover will be speaking at LinuxFest Northwest this year. See program highlights or register to attend.*

## 1 Comment