1. 概述

文件系统描述我们的数据。对于文件系统，我们有文件夹、访问控制和命名文件。没有它们，我们的磁盘将只是一堆位。我们不知道任何内容存储在哪里，事物从哪里开始或结束，或者任何外部信息（元数据）。

文件系统的首要任务是保证数据安全。我们希望我们的数据能够快速访问、易于管理，最重要的是，它必须正确且位于我们放置的位置。据统计，存储硬件故障（硬盘驱动器崩溃）非常常见。这意味着如果我们的数据对我们有价值，我们就需要更深入地研究存储管理。

Linux基础- Linux文件系统选型（linux文件系统推荐）

忽略文件系统并使用默认值很容易。在今天的 Linux 中，这意味着 ext4 或 XFS 文件系统。但我们还有其他更高级的选项：brtfs和ZFS。这些“下一代”文件系统让我们能够更灵活、更安全地处理更大的存储量。

在本文中，我们将研究从默认文件系统中获得的一些内容，以及下一代文件系统提供的内容。

2.默认值：ext4和XFS

随着时间的推移，这两个文件系统已经能够满足非常相似的需求。它们是快速且可靠的日志文件系统。自 2009 年 Karmic Koala 发布以来，Ubuntu 默认使用 ext4。2010年的Red Hat Enterprise Linux 6.0也使用了ext4。RHEL 7.0 于 2014 年迁移到 XFS。

文件系统是我们稳定系统的基本组成部分，因此内核和发行版维护人员在采用更改时会缓慢而谨慎地采取行动。

如果我们今天安装 Ubuntu 或 Debian，我们的存储将使用 ext4。如果我们安装 Red Hat Enterprise Linux 或 SuSE，我们将获得 XFS。

2.1.昨天的高科技：日志、范围和有限的校验和

自从引入 Linux 以来，这两个文件系统在功能上越来越接近。XFS 开始时比较先进，并且一直运行良好。然而，ext4 现在成功地添加了许多曾经使 XFS 与众不同的功能：

日志：文件系统“日志”将所有更改写入文件系统的重复日志。如果对文件系统的写入中断（断电），系统会检查日志并“回放”以最大程度地减少数据丢失和文件损坏。（以前，文件系统的正确性依赖于fsck等“检查器”工具。）
范围：传统上，文件系统会逐块维护其内容的“映射”。默认块通常为 4,096 字节，因此随着存储的增加，我们可以想象这些映射会变得有多大。相反，XFS 和 ext4 将数据块映射到称为“范围”的更大块中。具体来说，盘区映射是两个数字：起始块地址和盘区长度（以块为单位）。这对于大卷和大文件非常有效，无需跟踪每个块的文件成员资格。
校验和：我们如何知道我们的数据没有损坏？一种方法是计算校验和——一个较短的“幻数”，当我们的较大数据发生变化时，该校验和也会发生变化。我们过去通过运行检查和修复程序来做到这一点：很难发音的fsck。XFS 和 ext4 现在计算元数据及其日志文件的校验和。这很有用，尽管远不如 btrfs 和 ZFS 的逐块校验和完整。

尽管 ext4 和 XFS 都在各自领域表现出色，但它们都不适合应对当今一些更复杂的存储挑战。

2.2.ext 文件系统

“扩展文件系统”仍然是 Linux 中最流行的文件系统。从 1992 年的 ext 开始，文件系统在 1993 年迅速迁移到 ext2，在 2001 年通过 ext3 添加日志，并在 2008 年通过 ext4 进行了面向未来的调整。

ext4 文件系统延续了其前身的理念：快速并在损坏时进行修复。但是，ext3 和 ext4 添加了数据安全功能，例如日志和有限的校验和。

ext4 还可以实现更大的卷和文件（ext3 的最大容量为 16 TB）。它对范围的采用进一步有助于处理更大的文件，例如媒体和一些数据库。

但 ext4 也可以很好地处理许多较小文件的集合。它取消了 ext3 以前对子目录的限制（ext3 的最大数量是 32,000 个）。

ext 系列文件系统作为 Linux 默认文件系统能够持续这么久是有原因的：它是经过充分测试的主力，优先考虑速度和“足够好”的数据验证。

2.3.XFS：90 年代的“大铁”

Silicon Graphics, Inc. 于 1993 年为其 IRIX Unix 操作系统创建了 XFS。SGI 因突破计算机图形制作的极限而闻名。他们依靠自己定制的高端和高度并行硬件来实现这一目标。

因此，SGI 需要一个能够使用多个 CPU 和驱动控制器可靠地处理大文件的文件系统。可靠性意味着保留日志以避免文件损坏。处理大文件意味着使 XFS 成为 64 位（在 64 位很酷之前）。允许多个 CPU 读写这些巨型文件意味着 XFS 的开发人员需要取消在访问期间在 i 节点周围放置锁的标准做法。

我们可以想象允许数百个 CPU 核心同时访问会带来额外的复杂性！但设计如此细粒度的软件系统为其高度并行的硬件带来了回报。就像 macOS 和 iOS 适合 Apple 硬件一样，XFS 适合 SGI 的生态系统。

XFS 于 2001 年被移植到 Linux 并进入内核。现在几乎每个 Linux 发行版都可用且可靠。

如果我们正在构建一个具有大存储需求、大文件和多线程 I/O 的系统，我们应该考虑 XFS。但对于更小、更轻的负载，ext4 可能更适合我们。

我们的系统会通过媒体文件或大数据进行研磨吗？如果是这样，我们应该研究 XFS 或下一代文件系统之一。

我们会运行微服务吗？如果是这样的话，我们可能想坚持使用 ext4。

2.4.尝试一下

最后！让我们动手吧！体验不同文件系统的最简单方法是全新安装 Linux。但如果我们想在现有系统上进行实验，这也是一个选择。

ext4 文件系统已经无处不在。我们来看看/sbin目录：

$ ls -l /sbin/mkfs.ext*
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext2 -> mke2fs
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext3 -> mke2fs
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext4 -> mke2fs

这些链接可以方便地运行二进制mke2fs ，尽管我们也可以直接运行它并使用-t选项指定文件系统类型。

首先，我们将仔细检查我们没有意外破坏我们想要保留的文件系统。我们可以使用lsblk查看可用的块设备，并使用df比较已安装的设备。

然后，就像将mkfs程序指向设备一样简单：

$ sudo /sbin/mkfs.ex4 /dev/sdc复制

然后我们创建一个目录作为挂载点并运行mount。如果我们希望每次重新启动时都安装新的文件系统，我们将在fstab中添加一行。

如果我们想使用 XFS 来做到这一点，我们可能必须首先安装用户层工具。（对文件系统的支持已经内置到大多数内核中。我们只需要让我们创建和操作它的程序。）

在 Debian 和 Ubuntu 上，我们使用apt安装 xfsprogs 软件包：

$ sudo apt install xfsprogs

然后运行匹配的命令来使用 XFS 初始化我们的块设备：

$ sudo /sbin/mkfs.xfs /dev/sdc

安装完成后，我们可以进行实验，看看它如何满足我们的需求！

2.5.RAID 和逻辑卷管理器

虽然RAID和逻辑卷选项的详细检查需要单独的文章来讨论，但我们需要了解它们如何与文件系统交互。

RAID 和逻辑卷管理器执行不同的操作，但两者都允许我们将多个物理磁盘视为一个抽象卷。

我们不是直接在块设备上创建文件系统，而是将磁盘添加到一个集合中，然后将该集合视为具有一个文件系统的一个设备。

例如，我们可能有两个磁盘（物理卷，在 LVM2 的术语中）加入到一个虚拟卷中：

$ lsblk -f -e7 -o NAME,FSTYPE,FSVER,FSAVAIL,MOUNTPOINT
NAME                   FSTYPE      FSVER    FSAVAIL MOUNTPOINT
sda                                                 
├─sda1                 ext2        1.0        63.9M /boot
├─sda2                                              
└─sda5                 LVM2_member LVM2 001         
  ├─salvage--vg-root   ext4        1.0       388.7G /
  ├─salvage--vg-swap_1 swap        1                [SWAP]
  └─salvage--vg-home   ext4        1.0       274.2G /home
sdb                    LVM2_member LVM2 001         
└─salvage--vg-root     ext4        1.0       388.7G /

在这里，sda5分区和sdb驱动器都是物理驱动器（使用pvdisplay检查），收集到单个卷组（使用vgdisplay检查）并分配到文件系统所在的逻辑卷（使用lvdisplay检查）。

请注意根挂载点 ( salvage–vg-root ) 如何使用两个不同物理驱动器（sda5和sdb）的空间？现代 Linux 多年来一直使用lvm来做到这一点，允许我们使用所有可用空间或留出一些空间作为实时镜像副本。

我们还可以添加新的物理磁盘并调整卷和文件系统的大小。灵活一点就很方便了！

我们选择如何传播数据既有风险也有回报。如果一个磁盘坏了，我们会丢失数据吗？如果我们使用 10 个磁盘和两个芯片怎么样？

这些都是长期数据存储的重要问题，但 RAID 和 LVM 的“旧方式”解决方案对这些问题的回答却截然不同。ZFS 和 btrfs 为这些问题提供了更集成的方法，我们将在本文后面看到。

3. 下一代文件系统：什么以及为什么

老式且久经考验的文件系统具有所有这些出色的功能！为什么我们还需要更多东西？

事实上，一些用例可以通过传统且值得信赖的解决方案得到很好的服务。

但较新的文件系统解决并整合了存储问题。ZFS 结合了 RAID 控制器、卷管理器和文件系统。但它还做了更多的事情，重新思考文件系统的安装和共享方式。btrfs 实现了几个类似的功能目标，同时避免了重新设计我们关于存储的基本假设。

3.1.新热点：写入时复制、错误检测、快照和复制

btrfs 和 ZFS 都强调了与以前的文件系统相比的三个特定的设计和功能更改。

写时复制 (COW) 的工作原理是从不覆盖原地数据。我们不再需要担心文件或文件系统进入不一致的状态。在较旧的文件系统中，当出现问题（断电、由于硬件错误、宇宙射线导致位翻转）时，我们可能正在保存文件，并且该文件现在可能已损坏。

相反，使用 COW 文件系统，内存中的数据更改将写入磁盘的新区域。完成后，引用该文件的任何内容都会更改为指向磁盘上的新文件位置。

例如，目录条目保存其中所有文件及其块地址的列表。一旦新副本完成（而不是之前），目录条目就会更改为引用新的块地址。元数据更改通过类似的过程进行。

COW 的另一个关键要素是，如果文件没有更改，则不需要复制。相反，“浅拷贝”的工作方式有点像符号链接，仅在实际发生变化时复制数据。

错误检测现在由文件系统逐块完成。在过去的糟糕日子里，我们必须运行fsck来修复任何可能的数据错误。使用ext4或XFS，我们仍然需要等待日志重放。旧式 RAID 需要很长时间才能重建，因为它必须检查所有其他磁盘。

但更糟糕的是：我们现在知道，随着驱动器变得越来越大，越来越多的静默数据损坏错误未被检测到。拥有块级校验和使我们能够依靠文件系统来修复这些错误。

例如，ZFS 可能有一个文件分布在多个驱动器上，其各个块被镜像和复制。如果这些块之一被损坏，其校验和就会改变。

ZFS 计算该校验和及其镜像块的校验和。它将这些与上次更新块时存储的校验和进行比较。如果文件是好的，这些应该都是相同的。但如果一个坏了，我们就知道它已经损坏了。然后，ZFS 可以使用具有已知良好校验和的块自动“修复”损坏的块。

卷当前状态的快照允许回滚和复制。我们了解写入时复制意味着我们可以拥有影响较小的“浅”副本，这些副本仅在添加或更改数据时占用新空间。这使我们能够拍摄计算机状态的快照（类似于在进行危险更改之前对虚拟机进行快照的方式）。

我们还可以使用发送和接收命令来传输快照以及两个快照之间的差异。这些命令存在于 btrfs 和 ZFS 上。（甚至还有云复制服务！）

4. 更好/更好的文件系统

btrfs（即“ B-Tree ”文件系统）尝试以一种更简单的方式（并且许可问题更少）将 ZFS 的许多进步引入 Linux。它自 2009 年起就出现在 Linux 内核中，但仍在积极开发中。

它在大型数据中心得到了一些采用，但并不享有 ZFS 坚如磐石的稳定性的声誉。

4.1.btrfs 实践

体验 btrfs 最简单的方法之一是全新安装 Fedora 33 或更高版本。我们很容易就能轻松进入 btrfs，而无需了解其更复杂的功能。Fedora 安装如下所示：

$ lsblk -f -o NAME,FSTYPE,LABEL,MOUNTPOINT
NAME   FSTYPE LABEL                 MOUNTPOINT
sr0                                 
zram0                               [SWAP]
vda                                 
├─vda1 ext4                         /boot
└─vda2 btrfs  fedora_localhost-live /home

我们看到 ext4 仍然存在于 Fedora 的引导分区选择中。

如果我们想在 Ubuntu 或 Debian 上进行实验，我们需要一些额外的工具。就像我们对 XFS 所做的那样，我们将使用apt安装它们：

$ sudo apt install btrfs-progs

从那里，我们可以使用mkfs.btrfs创建新卷，并使用 btrfs 设备添加来扩展卷：

$ sudo mkfs.btrfs -L media -d raid1 /dev/vdb /dev/vdc
btrfs-progs v5.13 
See http://btrfs.wiki.kernel.org for more information.

Label:              media
UUID:               0ec28d06-b5a1-46f3-b628-30d04aeaaef3
Node size:          16384
Sector size:        4096
Filesystem size:    20.00GiB
Block group profiles:
  Data:             RAID1             1.00GiB
  Metadata:         RAID1           256.00MiB
  System:           RAID1             8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata
Runtime features:   
Checksum:           crc32c
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1    10.00GiB  /dev/vdb
    2    10.00GiB  /dev/vdc

此输出提供了大量详细信息和一些新术语，例如“扇区大小”。我们不会在这里讨论这些，但它们是有趣的起点。

与 ZFS 不同，我们必须安装新的 btrfs 卷。通过mount命令或在fstab中使用它的一种简单方法是通过其标签引用它：

# ls /dev/disk/by-label/
fedora_localhost-live  media
# mkdir /big-media; mount /dev/disk/by-label/media /big-media

4.2.高级功能和风险

简而言之，btrfs 可以用作简单的文件系统，也可以用作 RAID 控制器和文件系统。然而，其开发人员警告不要在生产中使用 RAID5。

当我们习惯了之后，我们可以使用btrfs命令探索更复杂的功能，例如：

btrfs 子卷来划分我们的卷并应用特定设置
btrfs 子卷快照，用于创建子卷的轻型“影子”副本以进行备份或配置管理
btrfs 平衡以在所有存储中重新分配已使用的块
btrfs send和btrfs receive在机器之间传输快照

btrfs 是一个不断变化的文件系统，对其使用的任何认真投资都必须伴随着对其常见问题解答的频繁引用。

5. ZFS：我们的一体化存储解决方案

ZFS 于 2005 年起源于 OpenSolaris。它很快被 Solaris 10 和开源 BSD 操作系统采用，并在 2014 年的 FreeBSD 10 中得到正式支持。

ZFS 让我们可以像逻辑卷管理器一样池化存储。它提供像 RAID 一样的数据和硬件冗余（尽管它更像是一个时髦且智能的JBOD）。

让我们尝试一下。

5.1.ZFS 实践

由于许可问题，ZFS 与 Linux 的历史更加复杂。目前在 Linux 上使用 ZFS 最直接的方法是使用 Ubuntu。我们可以安装zfsutils-linux软件包。或者，Canonical 默认将其捆绑在其安装程序映像中。

这是一个“高级功能”，但我们可以安装到 ZFS 并从 ZFS 引导。在这里，我们安装到虚拟测试系统上：

当我们选择“使用ZFS”后，其他一切都是透明的。消除复杂性并让我们获得有用的东西的方法，Canonical！

5.2.ZFS 池

试验我们的虚拟 Ubuntu ZFS 安装，我们看到这些块设备：

$ lsblk -e7 -f -o NAME,FSTYPE,LABEL,FSUSE%,MOUNTPOINT
NAME   FSTYPE     LABEL FSUSE% MOUNTPOINT
sr0                            
vda                            
├─vda1                         
├─vda2 vfat                 3% /boot/efi
├─vda3 swap                    [SWAP]
├─vda4 zfs_member bpool        
└─vda5 zfs_member rpool

那么bpool和rpool是什么？我们可以使用zpool命令检查：

$ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1.12G   148M  1004M        -         -     0%    12%  1.00x    ONLINE  -
rpool    22G  3.52G  18.5G        -         -     3%    16%  1.00x    ONLINE  -

唔。我们看到bpool是两者中较小的一个。如果我们查找的话，我们会发现 Ubuntu 已决定将安装分为“启动”池和“根”池。如果我们将这些与 LVM 示例中的分区方法进行比较，我们会记得非 ZFS Ubuntu 布局将/boot保留在专用的 ext2 分区上，将/home和/（根）保留在不同的逻辑卷上。

让我们看看 Ubuntu 如何组织我们的 ZFS 池：

$ zfs list
NAME                                               USED  AVAIL     REFER  MOUNTPOINT
bpool                                              147M   876M       96K  /boot
bpool/BOOT                                         147M   876M       96K  none
bpool/BOOT/ubuntu_70wzaj                           147M   876M     81.7M  /boot
rpool                                             3.52G  17.8G       96K  /
rpool/ROOT                                        3.51G  17.8G       96K  none
rpool/ROOT/ubuntu_70wzaj                          3.51G  17.8G     2.44G  /
rpool/ROOT/ubuntu_70wzaj/srv                        96K  17.8G       96K  /srv
rpool/ROOT/ubuntu_70wzaj/usr                       336K  17.8G       96K  /usr
rpool/ROOT/ubuntu_70wzaj/usr/local                 240K  17.8G      128K  /usr/local
rpool/ROOT/ubuntu_70wzaj/var                       993M  17.8G       96K  /var
rpool/ROOT/ubuntu_70wzaj/var/games                  96K  17.8G       96K  /var/games
rpool/ROOT/ubuntu_70wzaj/var/lib                   983M  17.8G      862M  /var/lib
rpool/ROOT/ubuntu_70wzaj/var/lib/AccountsService   168K  17.8G      104K  /var/lib/AccountsService
rpool/ROOT/ubuntu_70wzaj/var/lib/NetworkManager    404K  17.8G      140K  /var/lib/NetworkManager
rpool/ROOT/ubuntu_70wzaj/var/lib/apt              79.5M  17.8G     79.2M  /var/lib/apt
rpool/ROOT/ubuntu_70wzaj/var/lib/dpkg             40.2M  17.8G     31.2M  /var/lib/dpkg
rpool/ROOT/ubuntu_70wzaj/var/log                  8.41M  17.8G     3.19M  /var/log
rpool/ROOT/ubuntu_70wzaj/var/mail                   96K  17.8G       96K  /var/mail
rpool/ROOT/ubuntu_70wzaj/var/snap                  532K  17.8G      532K  /var/snap
rpool/ROOT/ubuntu_70wzaj/var/spool                 280K  17.8G      112K  /var/spool
rpool/ROOT/ubuntu_70wzaj/var/www                    96K  17.8G       96K  /var/www
rpool/USERDATA                                    4.99M  17.8G       96K  /
rpool/USERDATA/a_40qa3s                           4.73M  17.8G     2.43M  /home/a
rpool/USERDATA/root_40qa3s                         168K  17.8G      112K  /root

哇！Canonical 在rpool中设置了很多子文件系统。因此，我们对存储池的各个部分有非常细粒度的控制。如果我们向rpool 添加一个磁盘或磁盘集，我们就可以在任何地方使用该新空间。（向现有池添加存储有一些棘手的因素，因此在购买之前要进行研究。）

我们在这里看到的每个挂载点都可以有自己的设置——配额、压缩和 IO 调整更改。更好的是：默认情况下，它们从父级继承设置。如果我们使用zfs命令设置/var使用自动压缩：

$ sudo zfs set compression=lz4 rpool/ROOT/ubuntu_70wzaj/var

现在，/var下的所有内容也将使用 lz4 压缩。

这对于较小的系统来说可能并不重要，但如果我们需要扩大规模，我们会很高兴 ZFS 以这种方式工作。

5.3.创建我们自己的池

首先，我们只需要一个简单的命令。

好吧，在我们这样做之前，我们需要识别我们的磁盘。让我们向虚拟机添加两个小型存储设备。Ubuntu 的bpool和rpool安装在/dev/vda上，因此这两个将是/dev/vdb和/dev/vdc。

zpool有很多选项。zpool create将驱动器组装成 vdev（虚拟设备），并将 vdev 组装成池：

# zpool create mpool /dev/vdb /dev/vdc

或者，它可以创建由两个存储设备组成的单个镜像 vdev：

# zpool create mpool mirror /dev/vdb /dev/vdc

此命令要求 ZFS 创建一个新的存储池。该池将被命名为“mpool”，尽管我们可以随意称呼它。它将由镜像 vdev 组成，而镜像 vdev 又由vdb和vdc设备组成。

创建mpool后，我们使用zpool status 来检查其详细信息：

# zpool status mpool
  pool: mpool
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	mpool       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    vdb     ONLINE       0     0     0
	    vdc     ONLINE       0     0     0

errors: No known data errors

我们注意到它会自动安装：

# df /mpool
Filesystem     1K-blocks  Used Available Use% Mounted on
mpool            9650176   128   9650048   1% /mpool

我们可以轻松更改挂载点，但不必触及/etc/fstab。ZFS 将所有安装点存储为元数据。

5.4.ZFS 子卷

如果我们想组织我们的媒体池怎么办？也许我们希望每个人都使用不同的配额或透明地压缩我们池的一部分。

我们通过返回到zfs create命令来做到这一点：

# zfs create mpool/Movies
# zfs create mpool/Television
# zfs list -r mpool
NAME               USED  AVAIL     REFER  MOUNTPOINT
mpool              184K  9.20G       25K  /mpool
mpool/Movies        24K  9.20G       24K  /mpool/Movies
mpool/Television    24K  9.20G       24K  /mpool/Television

如果我们想摆脱“练习”池，很简单：

zpool destroy mpool

其他要探索的命令包括使用：

zpool 检查点保存池的当前状态
zpool 导入以允许操作系统使用现有池或检查点
zpool scrap，它验证校验和并自动修复任何错误
zfs 快照和zfs 回滚来管理整个 ZFS 系统的更改

5.5.ZFS设计

该框架向我们展示了 ZFS 如何处理存储。这是我们获得逻辑卷管理器和 RAID 功能的地方：

存储设备：物理磁盘和/或分区
虚拟设备：抽象存储、单个磁盘、镜像集合或 RAID-Z 阵列；由存储设备构建
存储池：运行zpool list时看到的 zpool 。这是我们的文件和目录所在的位置。

ZFS 将我们的存储池的数据分布到所有池的设备上。在这方面，它类似于 Linux 的逻辑卷管理器。如果我们包含镜像或 RAID-Z vdev，我们还将拥有数据冗余，并且能够从磁盘故障中恢复，而无需从完整备份中恢复。

需要注意的是，在向 zpool 添加更多 vdev 时，很难更改组成 vdev 的设备。我们不能简单地更改硬件配置并让文件系统处理它。与 Btrfs 不同，btrfs 可以非常顺利地处理这种情况，ZFS 更改可能需要更多规划，有时甚至需要从头开始。 即将推出的功能 draid有助于克服这种尴尬。

6.其他文件系统

由于历史或兼容性原因，Linux 支持许多文件系统。此外，我们经常希望通过网络共享或访问卷。

6.1.网络上的某个地方：NFS 和 SMB

NFS（网络文件系统）起源于 Unix，而 SMB 通常用于 Windows 和 macOS。当我们的 Linux 机器访问这些文件系统时，我们不必运行mkfs，但在安装它们之后，它们应该像任何本地文件系统一样透明地使用。

我们还可能会看到NAS，它只是一个专用文件服务器机器，通过 NFS、SMB 或其他网络文件协议共享空间。

另一方面，SAN 使用 iSCSI 或 FibreChannel 等协议通过网络在块级别连接存储。从Linux的角度来看，它只是另一个像硬盘一样的块设备。它可以被格式化或添加到 ZFS 池中。

6.2.亚马逊的弹性块存储（EBS）

同样，这个主题超出了本文的范围，但请注意，云提供商提供长期存储，可以将其视为块级设备。

AWS EBS透明地解决了短暂云实例的问题。我们可以使用我们在 EBS 上讨论过的任何文件系统。

与云实例一起使用时，下一代文件系统仍然不常见。例如，DigitalOcean 将自动设置块存储以使用 ext4 或 XFS。如果我们愿意自己动手，ZFS 或 btrfs 也可以。

采用速度缓慢的原因之一是 ZFS 对内存的高需求。我们可能试图通过使用较小的实例来节省资金。我们必须密切监视这样的环境。

6.3.进一步感兴趣

一旦我们对文件系统产生了兴趣，就会发现有很多东西需要研究：

Dominic Giampaolo 的书《Practical File System Design with the Be File System》提供了 1999 年左右文件系统技术状态的详细快照。
APFS，iOS 设备和现代 macOS 上使用的文件系统：它们对数百万活动设备的无缝转换是一个工程奇迹。
Microsoft NTFS中的巧妙设计选择。
Jim Salter关于下一代文件系统的博客和演示充满了具体细节。