Coding ManLinux文件系统简介
1. 概述
文件系统描述了我们的数据。对于文件系统，我们有文件夹、访问控制和命名文件。没有它们，我们的磁盘将只是一堆比特。我们不知道任何东西存储在哪里、事情从哪里开始或结束，或者任何外部信息（元数据）。
文件系统的首要任务是保护我们的数据安全。我们希望我们的数据能够快速访问、易于管理，最重要的是，它必须正确无误并且位于我们放置它的地方。从统计数据来看 ，存储硬件故障（硬盘驱动器崩溃）太常见了 。这意味着如果我们的数据对我们有价值，我们需要更深入地研究存储管理。
忽略文件系统并使用默认值很容易。在今天的 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 将数据块映射到称为“范围”的更大块中。具体来说，extent map 是两个数字：起始块地址和 extent 的长度（以块为单位）。这适用于大容量和大文件，无需跟踪每个块的文件成员资格。
- 校验和 ：我们如何知道我们的数据没有损坏？一种方法是计算校验和——一个较短的“幻数”，它会在我们较大的数据发生变化时发生变化。我们过去常常通过运行检查和修复程序来做到这一点：发音困难的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 年代的“Big Iron”
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 做到这一点，我们可能必须先安装 userland 工具。（对文件系统的支持已经内置到大多数内核中。我们只需要让我们创建和操作它的程序。）
在 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 个磁盘和两个 die 怎么样？
这些都是长期数据存储的重要问题，但 RAID 和 LVM 的“旧方法”解决方案对它们的回答截然不同。ZFS 和 btrfs 为这些问题带来了更集成的方法，我们将在本文后面看到。
3. 下一代文件系统：什么和为什么
老式且久经考验的文件系统具有所有这些强大的功能！为什么我们还需要更多东西？
事实上，一些用例可以通过传统和可信的解决方案得到很好的服务。
但是更新的文件系统解决并整合了存储问题。ZFS 结合了 RAID 控制器、卷管理器和文件系统。但它还有更多作用，重新思考文件系统的挂载和共享方式。btrfs 实现了几个类似的功能目标，同时避免了必须修改我们关于存储的基本假设。
3.1. 新热点：写时复制、错误检测、快照和复制
btrfs 和 ZFS 都强调了与以前的文件系统相比的三个特殊设计和功能变化。
**写时复制 (COW) 的工作原理是从不覆盖就地数据。**我们不再需要担心文件或文件系统进入不一致状态。在较旧的文件系统中，当出现问题（断电、由于硬件错误、宇宙射线导致的位翻转）时，我们可能正在保存文件，并且该文件现在可能已损坏。
相反，使用 COW 文件系统，内存中的数据更改将写入磁盘的新区域。完成后，任何引用该文件的内容都会更改为指向磁盘上的新文件位置。
例如，目录条目保存其中所有文件的列表及其块地址。一旦新副本完成——而不是之前——目录条目将更改为引用新的块地址。元数据更改通过类似的过程进行。
COW 的另一个关键要素是，如果文件没有更改，则不需要复制它。相反，“浅拷贝”的工作方式有点像符号链接，仅在实际发生变化时才复制数据。
**错误检测现在由文件系统逐块完成。**在糟糕的过去，我们必须运行fsck来修复任何可能的数据错误。使用ext4或者XFS，还是要等journal回放。旧式 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 在机器之间传输快照
Oracle Linux 记录了其中一些命令和更大的问题 。
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和/*（root）保留在不同的逻辑卷上。
让我们看看 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 checkpoint 保存池的当前状态
- *zpool import *允许操作系统使用现有的池或检查点
- zpool scrub *，*它验证校验和并自动修复任何错误
- zfs 快照 和zfs 回滚 以管理对整个 ZFS 系统的更改
5.5. ZFS 设计
该框架向我们展示了 ZFS 如何处理存储。这是我们获得逻辑卷管理器和 RAID 功能的地方：
- 存储设备：物理磁盘和/或分区
- 虚拟设备：抽象存储、单个磁盘、镜像集合或 RAID-Z 阵列；由存储设备构建
- 存储池：我们在运行zpool list 时看到的 zpool 。这是我们的文件和目录所在的地方。
**ZFS 将我们的存储池数据分布到所有池的设备上。**这样，它类似于 Linux 的逻辑卷管理器。如果我们包含镜像或 RAID-Z vdev，我们还将拥有数据冗余，并且能够从磁盘故障中恢复，而无需从完整备份中恢复。
重要的是要注意，在向 zpool 添加更多 vdev 时，很难更改组成 vdev 的设备。我们不能简单地更改我们的硬件配置并让文件系统处理它。与相当顺利地处理这种情况的 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. Amazon 的 Elastic Block Store (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 的博客 关于下一代文件系统的演示充满了细节。