虚拟文件系统是一种神奇的抽象，它使得 “一切皆文件” 哲学在 Linux 中成为了可能。

什么是文件系统？根据早期的 Linux 贡献者和作家 Robert Love 所说，“文件系统是一个遵循特定结构的数据的分层存储。” 不过，这种描述也同样适用于 VFAT（ 虚拟文件分配表 Virtual File Allocation Table ）、Git 和Cassandra（一种 NoSQL 数据库）。那么如何区别文件系统呢？

文件系统基础概念

Linux 内核要求文件系统必须是实体，它还必须在持久对象上实现 open()、read() 和 write() 方法，并且这些实体需要有与之关联的名字。从 面向对象编程 的角度来看，内核将通用文件系统视为一个抽象接口，这三大函数是“虚拟”的，没有默认定义。因此，内核的默认文件系统实现被称为虚拟文件系统（VFS）。

如果我们能够 open()、read() 和 write()，它就是一个文件，如这个主控台会话所示。

VFS 是著名的类 Unix 系统中 “一切皆文件” 概念的基础。让我们看一下它有多奇怪，上面的小小演示体现了字符设备 /dev/console 实际的工作。该图显示了一个在虚拟电传打字控制台（tty）上的交互式 Bash 会话。将一个字符串发送到虚拟控制台设备会使其显示在虚拟屏幕上。而 VFS 甚至还有其它更奇怪的属性。例如，它可以在其中寻址。

我们熟悉的文件系统如 ext4、NFS 和 /proc 都在名为 file\_operations 的 C 语言数据结构中提供了三大函数的定义。此外，个别的文件系统会以熟悉的面向对象的方式扩展和覆盖了 VFS 功能。正如 Robert Love 指出的那样，VFS 的抽象使 Linux 用户可以轻松地将文件复制到（或复制自）外部操作系统或抽象实体（如管道），而无需担心其内部数据格式。在用户空间这一侧，通过系统调用，进程可以使用文件系统方法之一 read() 从文件复制到内核的数据结构中，然后使用另一种文件系统的方法 write() 输出数据。

属于 VFS 基本类型的函数定义本身可以在内核源代码的 fs/*.c 文件 中找到，而 fs/ 的子目录中包含了特定的文件系统。内核还包含了类似文件系统的实体，例如 cgroup、/dev 和 tmpfs，在引导过程的早期需要它们，因此定义在内核的 init/ 子目录中。请注意，cgroup、/dev 和 tmpfs 不会调用 file_operations 的三大函数，而是直接读取和写入内存。

下图大致说明了用户空间如何访问通常挂载在 Linux 系统上的各种类型文件系统。像管道、dmesg 和 POSIX 时钟这样的结构在此图中未显示，它们也实现了 struct file_operations，而且其访问也要通过 VFS 层。

VFS 是个“垫片层”，位于系统调用和特定 file_operations 的实现（如 ext4 和 procfs）之间。然后，file_operations 函数可以与特定于设备的驱动程序或内存访问器进行通信。tmpfs、devtmpfs 和 cgroup 不使用 file_operations 而是直接访问内存。

VFS 的存在促进了代码重用，因为与文件系统相关的基本方法不需要由每种文件系统类型重新实现。代码重用是一种被广泛接受的软件工程最佳实践！唉，但是如果重用的代码引入了严重的错误，那么继承常用方法的所有实现都会受到影响。

/tmp：一个小提示

找出系统中存在的 VFS 的简单方法是键入 mount | grep -v sd | grep -v :/，在大多数计算机上，它将列出所有未驻留在磁盘上，同时也不是 NFS 的已挂载文件系统。其中一个列出的 VFS 挂载肯定是 /tmp，对吧？

谁都知道把 /tmp 放在物理存储设备上简直是疯了！图片：https://tinyurl.com/ybomxyfo

为什么把 /tmp 留在存储设备上是不可取的？因为 /tmp 中的文件是临时的（！），并且存储设备比内存慢，所以创建了 tmpfs 这种文件系统。此外，比起内存，物理设备频繁写入更容易磨损。最后，/tmp 中的文件可能包含敏感信息，因此在每次重新启动时让它们消失是一项功能。

不幸的是，默认情况下，某些 Linux 发行版的安装脚本仍会在存储设备上创建 /tmp。如果你的系统出现这种情况，请不要绝望。按照一直优秀的 Arch Wiki 上的简单说明来解决问题就行，记住分配给 tmpfs 的内存就不能用于其他目的了。换句话说，包含了大文件的庞大的 tmpfs 可能会让系统耗尽内存并崩溃。

另一个提示：编辑 /etc/fstab 文件时，请务必以换行符结束，否则系统将无法启动。（猜猜我怎么知道。）

/proc 和 /sys

除了 /tmp 之外，大多数 Linux 用户最熟悉的 VFS 是 /proc 和 /sys。（/dev 依赖于共享内存，而没有 file_operations 结构）。为什么有两种呢？让我们来看看更多细节。

procfs 为用户空间提供了内核及其控制的进程的瞬时状态的快照。在 /proc 中，内核发布有关其提供的设施的信息，如中断、虚拟内存和调度程序。此外，/proc/sys 是存放可以通过 sysctl 命令配置的设置的地方，可供用户空间访问。单个进程的状态和统计信息在 /proc/<PID> 目录中报告。

/proc/meminfo 是一个空文件，但仍包含有价值的信息。

/proc 文件的行为说明了 VFS 可以与磁盘上的文件系统不同。一方面，/proc/meminfo 包含了可由命令 free 展现出来的信息。另一方面，它还是空的！怎么会这样？这种情况让人联想起康奈尔大学物理学家 N. David Mermin 在 1985 年写的一篇名为《没有人看见月亮的情况吗？现实和量子理论》。事实是当进程从 /proc 请求数据时内核再收集有关内存的统计信息，而且当没有人查看它时，/proc 中的文件实际上没有任何内容。正如 Mermin 所说，“这是一个基本的量子学说，一般来说，测量不会揭示被测属性的预先存在的价值。”（关于月球的问题的答案留作练习。）

当没有进程访问它们时，/proc 中的文件为空。（来源）

procfs 的空文件是有道理的，因为那里可用的信息是动态的。sysfs 的情况则不同。让我们比较一下 /proc 与 /sys 中不为空的文件数量。

procfs 只有一个不为空的文件，即导出的内核配置，这是一个例外，因为每次启动只需要生成一次。另一方面，/sys 有许多更大一些的文件，其中大多数由一页内存组成。通常，sysfs 文件只包含一个数字或字符串，与通过读取 /proc/meminfo 等文件生成的信息表格形成鲜明对比。

sysfs 的目的是将内核称为 “kobject” 的可读写属性公开给用户空间。kobject 的唯一目的是引用计数：当删除对 kobject 的最后一个引用时，系统将回收与之关联的资源。然而，/sys 构成了内核著名的“到用户空间的稳定 ABI”，它的大部分内容在任何情况下都没有人能“破坏”。但这并不意味着 sysfs 中的文件是静态，这与易失性对象的引用计数相反。

内核的稳定 ABI 限制了 /sys 中可能出现的内容，而不是任何给定时刻实际存在的内容。列出 sysfs 中文件的权限可以了解如何设置或读取设备、模块、文件系统等的可配置、可调参数。逻辑上强调 procfs 也是内核稳定 ABI 的一部分的结论，尽管内核的文档没有明确说明。

sysfs 中的文件确切地描述了实体的每个属性，并且可以是可读的、可写的，或两者兼而有之。文件中的“0”表示 SSD 不可移动的存储设备。

用 eBPF 和 bcc 工具一窥 VFS 内部

了解内核如何管理 sysfs 文件的最简单方法是观察它的运行情况，在 ARM64 或 x86\_64 上观看的最简单方法是使用 eBPF。eBPF（ 扩展的伯克利数据包过滤器 extended Berkeley Packet Filter ）由在内核中运行的虚拟机组成，特权用户可以从命令行进行查询。内核源代码告诉读者内核可以做什么；而在一个启动的系统上运行 eBPF 工具会显示内核实际上做了什么。

令人高兴的是，通过 bcc 工具入门使用 eBPF 非常容易，这些工具在主要 Linux 发行版的软件包 中都有，并且已经由 Brendan Gregg 给出了充分的文档说明。bcc 工具是带有小段嵌入式 C 语言片段的 Python 脚本，这意味着任何对这两种语言熟悉的人都可以轻松修改它们。据当前统计，bcc/tools 中有 80 个 Python 脚本，使得系统管理员或开发人员很有可能能够找到与她/他的需求相关的已有脚本。

要了解 VFS 在正在运行中的系统上的工作情况，请尝试使用简单的 vfscount 或 vfsstat 脚本，这可以看到每秒都会发生数十次对 vfs_open() 及其相关的调用。

vfsstat.py 是一个带有嵌入式 C 片段的 Python 脚本，它只是计数 VFS 函数调用。

作为一个不太重要的例子，让我们看一下在运行的系统上插入 USB 记忆棒时 sysfs 中会发生什么。

用 eBPF 观察插入 USB 记忆棒时 /sys 中会发生什么，简单的和复杂的例子。

在上面的第一个简单示例中，只要 sysfs_create_files() 命令运行，trace.py bcc 工具脚本就会打印出一条消息。我们看到 sysfs_create_files() 由一个 kworker 线程启动，以响应 USB 棒的插入事件，但是它创建了什么文件？第二个例子说明了 eBPF 的强大能力。这里，trace.py 正在打印内核回溯（-K 选项）以及 sysfs_create_files() 创建的文件的名称。单引号内的代码段是一些 C 源代码，包括一个易于识别的格式字符串，所提供的 Python 脚本引入 LLVM 即时编译器（JIT） 来在内核虚拟机内编译和执行它。必须在第二个命令中重现完整的 sysfs_create_files() 函数签名，以便格式字符串可以引用其中一个参数。在此 C 片段中出错会导致可识别的 C 编译器错误。例如，如果省略 -I 参数，则结果为“无法编译 BPF 文本”。熟悉 C 或 Python 的开发人员会发现 bcc 工具易于扩展和修改。

插入 USB 记忆棒后，内核回溯显示 PID 7711 是一个 kworker 线程，它在 sysfs 中创建了一个名为 events 的文件。使用 sysfs_remove_files() 进行相应的调用表明，删除 USB 记忆棒会导致删除该 events 文件，这与引用计数的想法保持一致。在 USB 棒插入期间（未显示）在 eBPF 中观察 sysfs_create_link() 表明创建了不少于 48 个符号链接。

无论如何，events 文件的目的是什么？使用 cscope 查找函数 __device_add_disk() 显示它调用 disk_add_events()，并且可以将 “mediachange” 或 “ejectrequest” 写入到该文件。这里，内核的块层通知用户空间该 “磁盘” 的出现和消失。考虑一下这种检查 USB 棒的插入的工作原理的方法与试图仅从源头中找出该过程的速度有多快。

只读根文件系统使得嵌入式设备成为可能

确实，没有人通过拔出电源插头来关闭服务器或桌面系统。为什么？因为物理存储设备上挂载的文件系统可能有挂起的（未完成的）写入，并且记录其状态的数据结构可能与写入存储器的内容不同步。当发生这种情况时，系统所有者将不得不在下次启动时等待 fsck 文件系统恢复工具 运行完成，在最坏的情况下，实际上会丢失数据。

然而，狂热爱好者会听说许多物联网和嵌入式设备，如路由器、恒温器和汽车现在都运行着 Linux。许多这些设备几乎完全没有用户界面，并且没有办法干净地让它们“解除启动”。想一想启动电池耗尽的汽车，其中运行 Linux 的主机设备 的电源会不断加电断电。当引擎最终开始运行时，系统如何在没有长时间 fsck 的情况下启动呢？答案是嵌入式设备依赖于只读根文件系统（简称 ro-rootfs）。

ro-rootfs 是嵌入式系统不经常需要 fsck 的原因。 来源：https://tinyurl.com/yxoauoub

ro-rootfs 提供了许多优点，虽然这些优点不如耐用性那么显然。一个是，如果 Linux 进程不可以写入，那么恶意软件也无法写入 /usr 或 /lib。另一个是，基本上不可变的文件系统对于远程设备的现场支持至关重要，因为支持人员拥有理论上与现场相同的本地系统。也许最重要（但也是最微妙）的优势是 ro-rootfs 迫使开发人员在项目的设计阶段就决定好哪些系统对象是不可变的。处理 ro-rootfs 可能经常是不方便甚至是痛苦的，编程语言中的常量变量经常就是这样，但带来的好处很容易偿还这种额外的开销。

对于嵌入式开发人员，创建只读根文件系统确实需要做一些额外的工作，而这正是 VFS 的用武之地。Linux 需要 /var 中的文件可写，此外，嵌入式系统运行的许多流行应用程序会尝试在 $HOME 中创建配置的点文件。放在家目录中的配置文件的一种解决方案通常是预生成它们并将它们构建到 rootfs 中。对于 /var，一种方法是将其挂载在单独的可写分区上，而 / 本身以只读方式挂载。使用绑定或叠加挂载是另一种流行的替代方案。

绑定和叠加挂载以及在容器中的使用

运行 man mount 是了解 绑定挂载 bind mount 和 叠加挂载 overlay mount 的最好办法，这种方法使得嵌入式开发人员和系统管理员能够在一个路径位置创建文件系统，然后以另外一个路径将其提供给应用程序。对于嵌入式系统，这代表着可以将文件存储在 /var 中的不可写闪存设备上，但是在启动时将 tmpfs 中的路径叠加挂载或绑定挂载到 /var 路径上，这样应用程序就可以在那里随意写它们的内容了。下次加电时，/var 中的变化将会消失。叠加挂载为 tmpfs 和底层文件系统提供了联合，允许对 ro-rootfs 中的现有文件进行直接修改，而绑定挂载可以使新的空 tmpfs 目录在 ro-rootfs 路径中显示为可写。虽然叠加文件系统是一种适当的文件系统类型，而绑定挂载由 VFS 命名空间工具 实现的。

根据叠加挂载和绑定挂载的描述，没有人会对 Linux 容器 中大量使用它们感到惊讶。让我们通过运行 bcc 的 mountsnoop 工具监视当使用 systemd-nspawn 启动容器时会发生什么：

在 mountsnoop.py 运行的同时，system-nspawn 调用启动容器。

让我们看看发生了什么：

在容器 “启动” 期间运行 mountsnoop 可以看到容器运行时很大程度上依赖于绑定挂载。（仅显示冗长输出的开头）

这里，systemd-nspawn 将主机的 procfs 和 sysfs 中的选定文件按其 rootfs 中的路径提供给容器。除了设置绑定挂载时的 MS_BIND 标志之外，mount 系统调用的一些其它标志用于确定主机命名空间和容器中的更改之间的关系。例如，绑定挂载可以将 /proc 和 /sys 中的更改传播到容器，也可以隐藏它们，具体取决于调用。

总结

理解 Linux 内部结构看似是一项不可能完成的任务，因为除了 Linux 用户空间应用程序和 glibc 这样的 C 库中的系统调用接口，内核本身也包含大量代码。取得进展的一种方法是阅读一个内核子系统的源代码，重点是理解面向用户空间的系统调用和头文件以及主要的内核内部接口，这里以 file_operations 表为例。file_operations 使得“一切都是文件”得以可以实际工作，因此掌握它们收获特别大。顶级 fs/ 目录中的内核 C 源文件构成了虚拟文件系统的实现，虚拟文件​​系统是支持流行的文件系统和存储设备的广泛且相对简单的互操作性的垫片层。通过 Linux 命名空间进行绑定挂载和覆盖挂载是 VFS 魔术，它使容器和只读根文件系统成为可能。结合对源代码的研究，eBPF 内核工具及其 bcc 接口使得探测内核比以往任何时候都更简单。

非常感谢 Akkana Peck 和 Michael Eager 的评论和指正。

Alison Chaiken 也于 3 月 7 日至 10 日在加利福尼亚州帕萨迪纳举行的第 17 届南加州 Linux 博览会（SCaLE 17x）上演讲了本主题。

via: https://opensource.com/article/19/3/virtual-filesystems-linux

作者：Alison Chariken 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

学习在你的系统中创建一个文件系统，并且长期或者非长期地挂载它。

在计算技术中，文件系统控制如何存储和检索数据，并且帮助组织存储媒介中的文件。如果没有文件系统，信息将被存储为一个大数据块，而且你无法知道一条信息在哪结束，下一条信息在哪开始。文件系统通过为存储数据的文件提供名称，并且在文件系统中的磁盘上维护文件和目录表以及它们的开始和结束位置、总的大小等来帮助管理所有的这些信息。

在 Linux 中，当你创建一个硬盘分区或者逻辑卷之后，接下来通常是通过格式化这个分区或逻辑卷来创建文件系统。这个操作方法假设你已经知道如何创建分区或逻辑卷，并且你希望将它格式化为包含有文件系统，并且挂载它。

创建文件系统

假设你为你的系统添加了一块新的硬盘并且在它上面创建了一个叫 /dev/sda1 的分区。

1、为了验证 Linux 内核已经发现这个分区，你可以 cat 出 /proc/partitions 的内容，就像这样：

[root@localhost ~]# cat /proc/partitions
major minor  #blocks  name

 253            0   10485760 vda
 253            1       8192000 vda1
  11            0       1048575 sr0
  11            1       374 sr1
   8            0   10485760 sda
   8            1   10484736 sda1
 252            0       3145728 dm-0
 252            1       2097152 dm-1
 252            2       1048576 dm-2
   8    16      1048576 sdb

2、决定你想要去创建的文件系统种类，比如 ext4、XFS，或者其他的一些。这里是一些可选项：

[root@localhost ~]# mkfs.<tab><tab>
mkfs.btrfs mkfs.cramfs mkfs.ext2 mkfs.ext3 mkfs.ext4 mkfs.minix mkfs.xfs

3、为了这次练习的目的，选择 ext4。（我喜欢 ext4，因为如果你需要的话，它可以允许你去压缩文件系统，这对于 XFS 并不简单。）这里是完成它的方法（输出可能会因设备名称或者大小而不同）：

[root@localhost ~]# mkfs.ext4 /dev/sda1
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=8191 blocks
194688 inodes, 778241 blocks
38912 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=799014912
24 block groups
32768 blocks per group, 32768 fragments per group
8112 inodes per group
Superblock backups stored on blocks:
     32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

4、在上一步中，如果你想去创建不同的文件系统，请使用不同变种的 mkfs 命令。

挂载文件系统

当你创建好文件系统后，你可以在你的操作系统中挂载它。

1、首先，识别出新文件系统的 UUID 编码。使用 blkid 命令列出所有可识别的块存储设备并且在输出信息中查找 sda1：

[root@localhost ~]# blkid
/dev/vda1: UUID="716e713d-4e91-4186-81fd-c6cfa1b0974d" TYPE="xfs"
/dev/sr1: UUID="2019-03-08-16-17-02-00" LABEL="config-2" TYPE="iso9660"
/dev/sda1: UUID="wow9N8-dX2d-ETN4-zK09-Gr1k-qCVF-eCerbF" TYPE="LVM2_member"
/dev/mapper/test-test1: PTTYPE="dos"
/dev/sda1: UUID="ac96b366-0cdd-4e4c-9493-bb93531be644" TYPE="ext4"
[root@localhost ~]#

2、运行下面的命令挂载 /dev/sd1 设备：

[root@localhost ~]# mkdir /mnt/mount_point_for_dev_sda1
[root@localhost ~]# ls /mnt/
mount_point_for_dev_sda1
[root@localhost ~]# mount -t ext4 /dev/sda1 /mnt/mount_point_for_dev_sda1/
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 7.9G 920M 7.0G 12% /
devtmpfs 443M 0 443M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 30M 434M 7% /run
tmpfs 463M 0 463M 0% /sys/fs/cgroup
tmpfs 93M 0 93M 0% /run/user/0
/dev/sda1 2.9G 9.0M 2.7G 1% /mnt/mount_point_for_dev_sda1
[root@localhost ~]#

命令 df -h 显示了每个文件系统被挂载的挂载点。查找 /dev/sd1。上面的挂载命令使用的设备名称是 /dev/sda1。用 blkid 命令中的 UUID 编码替换它。注意，在 /mnt 下一个被新创建的目录挂载了 /dev/sda1。

3、直接在命令行下使用挂载命令（就像上一步一样）会有一个问题，那就是挂载不会在设备重启后存在。为使永久性地挂载文件系统，编辑 /etc/fstab 文件去包含你的挂载信息：

UUID=ac96b366-0cdd-4e4c-9493-bb93531be644 /mnt/mount_point_for_dev_sda1/ ext4 defaults 0 0

4、编辑完 /etc/fstab 文件后，你可以 umount /mnt/mount_point_for_fev_sda1 并且运行 mount -a 命令去挂载被列在 /etc/fstab 文件中的所有设备文件。如果一切顺利的话，你可以使用 df -h 列出并且查看你挂载的文件系统：

root@localhost ~]# umount /mnt/mount_point_for_dev_sda1/
[root@localhost ~]# mount -a
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 7.9G 920M 7.0G 12% /
devtmpfs 443M 0 443M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 30M 434M 7% /run
tmpfs 463M 0 463M 0% /sys/fs/cgroup
tmpfs 93M 0 93M 0% /run/user/0
/dev/sda1 2.9G 9.0M 2.7G 1% /mnt/mount_point_for_dev_sda1

5、你也可以检测文件系统是否被挂载：

[root@localhost ~]# mount | grep ^/dev/sd
/dev/sda1 on /mnt/mount_point_for_dev_sda1 type ext4 (rw,relatime,seclabel,stripe=8191,data=ordered)

现在你已经知道如何去创建文件系统并且长期或者非长期的挂载在你的系统中。

via: https://opensource.com/article/19/4/create-filesystem-linux-partition

作者：Kedar Vijay Kulkarni (Red Hat) 选题：lujun9972 译者：liujing97 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这里有所有你想知道的关于设置存储器而又不敢问的一切。

在大多数的计算机系统上，Linux 或者是其它，当你插入一个 USB 设备时，你会注意到一个提示驱动器存在的警告。如果该驱动器已经按你想要的进行分区和格式化，你只需要你的计算机在文件管理器或桌面上的某个地方列出驱动器。这是一个简单的要求，而且通常计算机都能满足。

然而，有时候，驱动器并没有按你想要的方式进行格式化。对于这些，你必须知道如何查找准备连接到您计算机上的存储设备。

什么是块设备？

硬盘驱动器通常被称为“块设备”，因为硬盘驱动器以固定大小的块进行读写。这就可以区分硬盘驱动器和其它可能插入到您计算机的一些设备，如打印机、游戏手柄、麦克风，或相机。一个简单的方法用来列出连接到你 Linux 系统上的块设备就是使用 lsblk （list block devices）命令：

NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                    8:0    0 238.5G  0 disk  
├─sda1                 8:1    0     1G  0 part  /boot
└─sda2                 8:2    0 237.5G  0 part  
  └─luks-e2bb...e9f8 253:0    0 237.5G  0 crypt 
        ├─fedora-root    253:1    0    50G  0 lvm   /
        ├─fedora-swap    253:2    0   5.8G  0 lvm   [SWAP]
        └─fedora-home    253:3    0 181.7G  0 lvm   /home
sdb                   8:16    1  14.6G  0 disk  
└─sdb1                8:17    1  14.6G  0 part

最左列是设备标识符，每个都是以 sd 开头，并以一个字母结尾，字母从 a 开始。每个块设备上的分区分配一个数字，从 1 开始。例如，第一个设备上的第二个分区用 sda2 表示。如果你不确定到底是哪个分区，那也不要紧，只需接着往下读。

lsblk 命令是无损的，仅仅用于检测，所以你可以放心的使用而不用担心破坏你驱动器上的数据。

使用 dmesg 进行测试

如果你有疑问，你可以通过在 dmesg 命令的最后几行查看驱动器的卷标，这个命令显示了操作系统最近的日志（比如说插入或移除一个驱动器）。一句话，如果你想确认你插入的设备是不是 /dev/sdc ，那么，把设备插到你的计算机上，然后运行这个 dmesg 命令：

$ sudo dmesg | tail

显示中列出的最新的驱动器就是你刚刚插入的那个。如果你拔掉它，并再运行这个命令一次，你可以看到，这个设备已经被移除。如果你再插上它再运行命令，这个设备又会出现在那里。换句话说，你可以监控内核对驱动器的识别。

理解文件系统

如果你只需要设备卷标，那么你的工作就完成了。但是如果你的目的是想创建一个可用的驱动器，那你还必须给这个驱动器做一个文件系统。

如果你还不知道什么是文件系统，那么通过了解当没有文件系统时会发生什么可能会更容易理解这个概念。如果你有多余的设备驱动器，并且上面没有什么重要的数据资料，你可以跟着做一下下面的这个实验。否则，请不要尝试，因为根据其设计目的，这个肯定会删除您的资料。

当一个驱动器没有文件系统时也是可以使用的。一旦你已经肯定，正确识别了一个驱动器，并且已经确定上面没有任何重要的资料，那就可以把它插到你的计算机上 —— 但是不要挂载它，如果它被自动挂载上了，那就请手动卸载掉它。

$ su -
# umount /dev/sdx{,1}

为了防止灾难性的复制 —— 粘贴错误，下面的例子将使用不太可能出现的 sdx 来作为驱动器的卷标。

现在，这个驱动器已经被卸载了，尝试使用下面的命令：

# echo 'hello world' > /dev/sdx

你已经可以将数据写入到块设备中，而无需将其挂载到你的操作系统上，也不需要一个文件系统。

再把刚写入的数据取出来，你可以看到驱动器上的原始数据：

# head -n 1 /dev/sdx
hello world

这看起来工作得很好，但是想象一下如果 “hello world” 这个短语是一个文件，如果你想要用这种方法写入一个新的文件，则必须：

1. 知道第 1 行已经存在一个文件了
2. 知道已经存在的文件只占用了 1 行
3. 创建一种新的方法来在后面添加数据，或者在写第 2 行的时候重写第 1 行

例如：

# echo 'hello world
> this is a second file' >> /dev/sdx

获取第 1 个文件，没有任何改变。

# head -n 1 /dev/sdx
hello world

但是，获取第 2 个文件的时候就显得有点复杂了。

# head -n 2 /dev/sdx | tail -n 1
this is a second file

显然，通过这种方式读写数据并不实用，因此，开发人员创建了一个系统来跟踪文件的组成，并标识一个文件的开始和结束，等等。

大多数的文件系统都需要一个分区。

创建分区

分区是硬盘驱动器的一种边界，用来告诉文件系统它可以占用哪些空间。举例来说，你有一个 4GB 的 USB 驱动器，你可以只分一个分区占用一个驱动器 （4GB），或两个分区，每个 2GB (又或者是一个 1GB，一个 3GB，只要你愿意)，或者三个不同的尺寸大小，等等。这种组合将是无穷无尽的。

假设你的驱动器是 4GB，你可以使用 GNU parted 命令来创建一个大的分区。

# parted /dev/sdx --align opt mklabel msdos 0 4G

按 parted 命令的要求，首先指定了驱动器的路径。

--align 选项让 parted 命令自动选择一个最佳的开始点和结束点。

mklabel 命令在驱动器上创建了一个分区表 （称为磁盘卷标）。这个例子使用了 msdos 磁盘卷标，因为它是一个非常兼容和流行的卷标，虽然 gpt 正变得越来越普遍。

最后定义了分区所需的起点和终点。因为使用了 --align opt 标志，所以 parted 将根据需要调整大小以优化驱动器的性能，但这些数字仍然可以做为参考。

接下来，创建实际的分区。如果你开始点和结束点的选择并不是最优的， parted 会向您发出警告并让您做出调整。

# parted /dev/sdx -a opt mkpart primary 0 4G

Warning: The resulting partition is not properly aligned for best performance: 1s % 2048s != 0s
Ignore/Cancel? C                                                          
# parted /dev/sdx -a opt mkpart primary 2048s 4G

如果你再次运行 lsblk 命令，（你可能必须要拔掉驱动器，并把它再插回去），你就可以看到你的驱动器上现在已经有一个分区了。

手动创建一个文件系统

我们有很多文件系统可以使用。有些是开源和免费的，另外的一些并不是。一些公司拒绝支持开源文件系统，所以他们的用户无法使用开源的文件系统读取，而开源的用户也无法在不对其进行逆向工程的情况下从封闭的文件系统中读取。

尽管有这种特殊的情况存在，还是仍然有很多文件系统可以使用，选择哪个取决于驱动器的用途。如果你希望你的驱动器兼容多个系统，那么你唯一的选择是 exFAT 文件系统。然而微软尚未向任何开源内核提交 exFAT 的代码，因此你可能必须在软件包管理器中安装 exFAT 支持，但是 Windows 和 MacOS 都支持 exFAT 文件系统。

一旦你安装了 exFAT 支持，你可以在驱动器上你创建好的分区中创建一个 exFAT 文件系统。

# mkfs.exfat -n myExFatDrive /dev/sdx1

现在你的驱动器可由封闭系统和其它开源的系统（尚未经过微软批准）内核模块进行读写了。

Linux 中常见的文件系统是 ext4。但对于便携式的设备来说，这可能是一个麻烦的文件系统，因为它保留了用户的权限，这些权限通常因为计算机而异，但是它通常是一个可靠而灵活的文件系统。只要你熟悉管理权限，那 ext4 对于便携式的设备来说就是一个很棒的文件系统。

# mkfs.ext4 -L myExt4Drive /dev/sdx1

拔掉你的驱动器，再把它插回去。对于 ext4 文件系统的便携设备来说，使用 sudo 创建一个目录，并将该目录的权限授予用户和系统中通用的组。如果你不确定使用哪个用户和组，也可以使用 sudo 或 root 来修改出现问题的设备的读写权限。

使用桌面工具

很高兴知道了在只有一个 Linux shell 的时候如何操作和处理你的块设备，但是，有时候你仅仅是想让一个驱动器可用，而不需要进行那么多的检测。 GNOME 的 KDE 的开发者们提供了这样的一些优秀的工具让这个过程变得简单。

GNOME 磁盘 和 KDE 分区管理器 是一个图形化的工具，为本文到目前为止提到的一切提供了一个一体化的解决方案。启动其中的任何一个，来查看所有连接的设备（在左侧列表中），创建和调整分区大小，和创建文件系统。

KDE 分区管理器

可以预见的是，GNOME 版本会比 KDE 版本更加简单，因此，我将使用复杂的版本进行演示——如果你愿意动手的话，很容易弄清楚 GNOME 磁盘工具的使用。

启动 KDE 分区管理工具，然后输入你的 root 密码。

在最左边的一列，选择你想要格式化的驱动器。如果你的驱动器并没有列出来，确认下是否已经插好，然后选择 “Tools > Refresh devices” （或使用键盘上的 F5 键）。

除非你想销毁驱动器已经存在的分区表，否则请勿继续。选择好驱动器后，单击顶部工具栏中的 “New Partition Table” 。系统会提示你为该分区选择一种卷标：gpt 或 msdos 。前者更加灵活可以处理更大的驱动器，而后者像很多微软的技术一样，是占据大量市场份额的事实上的标准。

现在您有了一个新的分区表，在右侧的面板中右键单击你的设备，然后选择 “New” 来创建新的分区，按照提示设置分区的类型和大小。此操作包括了分区步骤和创建文件系统。

创建一个新分区

要将更改应用于你的驱动器，单击窗口左上角的 “Apply” 按钮。

硬盘驱动器，轻松驱动

在 Linux 上处理硬盘驱动器很容易，甚至如果你理解硬盘驱动器的语言就更容易了。自从切换到 Linux 系统以来，我已经能够以任何我想要的方式来处理我的硬盘驱动器了。由于 Linux 在处理存储提供的透明性，因此恢复数据也变得更加容易了。

如果你想实验并了解有关硬盘驱动器的更多的信息，请参考下面的几个提示：

1. 备份您的数据，而不仅仅是你在实验的驱动器上。仅仅需要一个小小的错误操作来破坏一个重要驱动器的分区。（这是一个用来学习重建丢失分区的很好的方法，但并不是很有趣）。
2. 反复确认你所定位的驱动器是正确的驱动器。我经常使用 lsblk 来确定我并没有移动驱动器。（因为从两个独立的 USB 端口移除两个驱动器很容易，然后以不同的顺序重新连接它们，就会很容易导致它们获得了新的驱动器标签。）
3. 花点时间“销毁”你测试的驱动器，看看你是否可以把数据恢复。在删除文件系统后，重新创建分区表或尝试恢复数据是一个很好的学习体验。

还有一些更好玩的东西，如果你身边有一个封闭的操作系统，在上面尝试使用一个开源的文件系统。有一些项目致力于解决这种兼容性，并且尝试让它们以一种可靠稳定的方式工作是一个很好的业余项目。

via: https://opensource.com/article/18/11/partition-format-drive-linux

作者：Seth Kenlon 选题：lujun9972 译者：Jamskr 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如你所知，Linux 支持非常多的文件系统，例如 ext4、ext3、ext2、sysfs、securityfs、FAT16、FAT32、NTFS 等等，当前被使用最多的文件系统是 ext4。你曾经疑惑过你的 Linux 系统使用的是什么类型的文件系统吗？没有疑惑过？不用担心！我们将帮助你。本指南将解释如何在类 Unix 的操作系统中查看已挂载的文件系统类型。

在 Linux 中查看已挂载的文件系统类型

有很多种方法可以在 Linux 中查看已挂载的文件系统类型，下面我将给出 8 种不同的方法。那现在就让我们开始吧！

方法 1 – 使用 findmnt 命令

这是查出文件系统类型最常使用的方法。findmnt 命令将列出所有已挂载的文件系统或者搜索出某个文件系统。findmnt 命令能够在 /etc/fstab、/etc/mtab 或 /proc/self/mountinfo 这几个文件中进行搜索。

findmnt 预装在大多数的 Linux 发行版中，因为它是 util-linux 包的一部分。如果 findmnt 命令不可用，你可以安装这个软件包。例如，你可以使用下面的命令在基于 Debian 的系统中安装 util-linux 包：

$ sudo apt install util-linux

下面让我们继续看看如何使用 findmnt 来找出已挂载的文件系统。

假如你只敲 findmnt 命令而不带任何的参数或选项，它将像下面展示的那样以树状图形式列举出所有已挂载的文件系统。

$ findmnt

示例输出：

正如你看到的那样，findmnt 展示出了目标挂载点（TARGET）、源设备（SOURCE）、文件系统类型（FSTYPE）以及相关的挂载选项（OPTIONS），例如文件系统是否是可读可写或者只读的。以我的系统为例，我的根（/）文件系统的类型是 EXT4 。

假如你不想以树状图的形式来展示输出，可以使用 -l 选项来以简单平凡的形式来展示输出：

$ findmnt -l

你还可以使用 -t 选项来列举出特定类型的文件系统，例如下面展示的 ext4 文件系统类型：

$ findmnt -t ext4
TARGET  SOURCE    FSTYPE OPTIONS
/       /dev/sda2 ext4   rw,relatime,commit=360
└─/boot /dev/sda1 ext4   rw,relatime,commit=360,data=ordered

findmnt 还可以生成 df 类型的输出，使用命令

$ findmnt --df

或

$ findmnt -D

示例输出：

SOURCE     FSTYPE            SIZE    USED   AVAIL   USE% TARGET
dev        devtmpfs          3.9G       0    3.9G     0% /dev
run        tmpfs             3.9G    1.1M    3.9G     0% /run
/dev/sda2  ext4            456.3G  342.5G   90.6G    75% /
tmpfs      tmpfs             3.9G   32.2M    3.8G     1% /dev/shm
tmpfs      tmpfs             3.9G       0    3.9G     0% /sys/fs/cgroup
bpf        bpf                  0       0       0      - /sys/fs/bpf
tmpfs      tmpfs             3.9G    8.4M    3.9G     0% /tmp
/dev/loop0 squashfs         82.1M   82.1M       0   100% /var/lib/snapd/snap/core/4327
/dev/sda1  ext4             92.8M   55.7M   30.1M    60% /boot
tmpfs      tmpfs           788.8M     32K  788.8M     0% /run/user/1000
gvfsd-fuse fuse.gvfsd-fuse      0       0       0      - /run/user/1000/gvfs

你还可以展示某个特定设备或者挂载点的文件系统类型。

查看某个特定的设备：

$ findmnt /dev/sda1
TARGET SOURCE    FSTYPE OPTIONS
/boot  /dev/sda1 ext4   rw,relatime,commit=360,data=ordered

查看某个特定的挂载点：

$ findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,relatime,commit=360

你甚至还可以查看某个特定标签的文件系统的类型：

$ findmnt LABEL=Storage

更多详情，请参考其 man 手册。

$ man findmnt

findmnt 命令已足够完成在 Linux 中查看已挂载文件系统类型的任务，这个命令就是为了这个特定任务而生的。然而，还存在其他方法来查看文件系统的类型，假如你感兴趣的话，请接着往下看。

方法 2 – 使用 blkid 命令

blkid 命令被用来查找和打印块设备的属性。它也是 util-linux 包的一部分，所以你不必再安装它。

为了使用 blkid 命令来查看某个文件系统的类型，可以运行：

$ blkid /dev/sda1

方法 3 – 使用 df 命令

在类 Unix 的操作系统中，df 命令被用来报告文件系统的磁盘空间使用情况。为了查看所有已挂载文件系统的类型，只需要运行：

$ df -T

示例输出：

关于 df 命令的更多细节，可以参考下面的指南。

• 针对新手的 df 命令教程

同样也可以参考其 man 手册：

$ man df

方法 4 – 使用 file 命令

file 命令可以判读出某个特定文件的类型，即便该文件没有文件后缀名也同样适用。

运行下面的命令来找出某个特定分区的文件系统类型：

$ sudo file -sL /dev/sda1
[sudo] password for sk:
/dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=83a1dbbf-1e15-4b45-94fe-134d3872af96 (needs journal recovery) (extents) (large files) (huge files)

查看其 man 手册可以知晓更多细节：

$ man file

方法 5 – 使用 fsck 命令

fsck 命令被用来检查某个文件系统是否健全或者修复它。你可以像下面那样通过将分区名字作为 fsck 的参数来查看该分区的文件系统类型：

$ fsck -N /dev/sda1
fsck from util-linux 2.32
[/usr/bin/fsck.ext4 (1) -- /boot] fsck.ext4 /dev/sda1

如果想知道更多的内容，请查看其 man 手册：

$ man fsck

方法 6 – 使用 fstab 命令

fstab 是一个包含文件系统静态信息的文件。这个文件通常包含了挂载点、文件系统类型和挂载选项等信息。

要查看某个文件系统的类型，只需要运行：

$ cat /etc/fstab

更多详情，请查看其 man 手册：

$ man fstab

方法 7 – 使用 lsblk 命令

lsblk 命令可以展示设备的信息。

要展示已挂载文件系统的信息，只需运行：

$ lsblk -f
NAME   FSTYPE   LABEL  UUID                                 MOUNTPOINT
loop0  squashfs                                             /var/lib/snapd/snap/core/4327
sda
├─sda1 ext4            83a1dbbf-1e15-4b45-94fe-134d3872af96 /boot
├─sda2 ext4            4d25ddb0-5b20-40b4-ae35-ef96376d6594 /
└─sda3 swap            1f8f5e2e-7c17-4f35-97e6-8bce7a4849cb [SWAP]
sr0

更多细节，可以参考它的 man 手册：

$ man lsblk

方法 8 – 使用 mount 命令

mount 被用来在类 Unix 系统中挂载本地或远程的文件系统。

要使用 mount 命令查看文件系统的类型，可以像下面这样做：

$ mount | grep "^/dev"
/dev/sda2 on / type ext4 (rw,relatime,commit=360)
/dev/sda1 on /boot type ext4 (rw,relatime,commit=360,data=ordered)

更多详情，请参考其 man 手册的内容：

$ man mount

好了，上面便是今天的全部内容了。现在你知道了 8 种不同的 Linux 命令来查看已挂载的 Linux 文件系统的类型。假如你知道其他的命令来完成同样的任务，请在下面的评论部分让我们知晓，我将确认并相应地升级本教程。

更过精彩内容即将呈现，请保持关注！

via: https://www.ostechnix.com/how-to-find-the-mounted-filesystem-type-in-linux/

作者：SK 选题：lujun9972 译者：FSSlc 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

今天，我们来谈论一下 ZFS，一个先进的文件系统。我们将讨论 ZFS 从何而来，它是什么，以及为什么它在科技界和企业界如此受欢迎。

虽然我是一个美国人，但我更喜欢读成 ZedFS 而不是 ZeeFS，因为前者听起来更酷一些。你可以根据你的个人喜好来发音。

注意：在这篇文章中，你将会看到 ZFS 被提到很多次。当我在谈论特性和安装的时候，我所指的是 OpenZFS 。自从 甲骨文 Oracle 公司放弃 OpenSolaris 项目之后，ZFS（由甲骨文公司开发）和 OpenZFS 已经走向了不同的发展道路。

ZFS 的历史

Z 文件系统 Z File System （ZFS）是由 Matthew Ahrens 和 Jeff Bonwick 在 2001 年开发的。ZFS 是作为 太阳微系统 Sun MicroSystem 公司的 OpenSolaris 的下一代文件系统而设计的。在 2008 年，ZFS 被移植到了 FreeBSD 。同一年，一个移植 ZFS 到 Linux 的项目也启动了。然而，由于 ZFS 是 通用开发和发布许可证 Common Development and Distribution License （CDDL）许可的，它和 GNU 通用公共许可证 不兼容，因此不能将它迁移到 Linux 内核中。为了解决这个问题，绝大多数 Linux 发行版提供了一些方法来安装 ZFS　。

在甲骨文公司收购太阳微系统公司之后不久，OpenSolaris 就闭源了，这使得 ZFS 的之后的开发也变成闭源的了。许多 ZFS 开发者对这件事情非常不满。三分之二的 ZFS 核心开发者，包括 Ahrens 和 Bonwick，因为这个决定而离开了甲骨文公司。他们加入了其它公司，并于 2013 年 9 月创立了 OpenZFS 这一项目。该项目引领着 ZFS 的开源开发。

让我们回到上面提到的许可证问题上。既然 OpenZFS 项目已经和 Oracle 公司分离开了，有人可能好奇他们为什么不使用和 GPL 兼容的许可证，这样就可以把它加入到 Linux 内核中了。根据 OpenZFS 官网 的介绍，更改许可证需要联系所有为当前 OpenZFS 实现贡献过代码的人（包括初始的公共 ZFS 代码以及 OpenSolaris 代码），并得到他们的许可才行。这几乎是不可能的（因为一些贡献者可能已经去世了或者很难找到），因此他们决定保留原来的许可证。

ZFS 是什么，它有什么特性？

正如前面所说过的，ZFS 是一个先进的文件系统。因此，它有一些有趣的特性。比如：

• 存储池
• 写时拷贝
• 快照
• 数据完整性验证和自动修复
• RAID-Z
• 最大单个文件大小为 16 EB（1 EB = 1024 PB）
• 最大 256 千万亿（256*10 ¹⁵ ）的 ZB（1 ZB = 1024 EB）的存储

让我们来深入了解一下其中一些特性。

存储池

与大多数文件系统不同，ZFS 结合了文件系统和卷管理器的特性。这意味着，它与其他文件系统不同，ZFS 可以创建跨越一系列硬盘或池的文件系统。不仅如此，你还可以通过添加硬盘来增大池的存储容量。ZFS 可以进行分区和格式化。

ZFS 存储池

写时拷贝

写时拷贝 Copy-on-write 是另一个有趣并且很酷的特性。在大多数文件系统上，当数据被重写时，它将永久丢失。而在 ZFS 中，新数据会写到不同的块。写完成之后，更新文件系统元数据信息，使之指向新的数据块（LCTT 译注：更新之后，原数据块成为磁盘上的垃圾，需要有对应的垃圾回收机制）。这确保了如果在写新数据的时候系统崩溃（或者发生其它事，比如突然断电），那么原数据将会保存下来。这也意味着，在系统发生崩溃之后，不需要运行 fsck 来检查和修复文件系统。

快照

写时拷贝使得 ZFS 有了另一个特性： 快照 snapshots 。ZFS 使用快照来跟踪文件系统中的更改。快照包含文件系统的原始版本（文件系统的一个只读版本），实时文件系统则包含了自从快照创建之后的任何更改。没有使用额外的空间。因为新数据将会写到实时文件系统新分配的块上。如果一个文件被删除了，那么它在快照中的索引也会被删除。所以，快照主要是用来跟踪文件的更改，而不是文件的增加和创建。

快照可以挂载成只读的，以用来恢复一个文件的过去版本。实时文件系统也可以回滚到之前的快照。回滚之后，自从快照创建之后的所有更改将会丢失。

数据完整性验证和自动修复

当向 ZFS 写入新数据时，会创建该数据的校验和。在读取数据的时候，使用校验和进行验证。如果前后校验和不匹配，那么就说明检测到了错误，然后，ZFS 会尝试自动修正错误。

RAID-Z

ZFS 不需要任何额外软件或硬件就可以处理 RAID（磁盘阵列）。毫不奇怪，因为 ZFS 有自己的 RAID 实现：RAID-Z 。RAID-Z 是 RAID-5 的一个变种，不过它克服了 RAID-5 的写漏洞：意外重启之后，数据和校验信息会变得不同步（LCTT 译注：RAID-5 的条带在正写入数据时，如果这时候电源中断，那么奇偶校验数据将跟该部分数据不同步，因此前边的写无效；RAID-Z 用了 “可变宽的 RAID 条带” 技术，因此所有的写都是全条带写入）。为了使用基本级别的 RAID-Z（RAID-Z1），你需要至少三块磁盘，其中两块用来存储数据，另外一块用来存储奇偶校验信息。而 RAID-Z2 需要至少两块磁盘存储数据以及两块磁盘存储校验信息。RAID-Z3 需要至少两块磁盘存储数据以及三块磁盘存储校验信息。另外，只能向 RAID-Z 池中加入偶数倍的磁盘，而不能是奇数倍的。

巨大的存储潜力

创建 ZFS 的时候，它是作为最后一个文件系统而设计的 。那时候，大多数文件系统都是 64 位的，ZFS 的创建者决定直接跳到 128 位，等到将来再来证明这是对的。这意味着 ZFS 的容量大小是 32 位或 64 位文件系统的 1600 亿亿倍。事实上，Jeff Bonwick（其中一个创建者）说：“完全填满一个 128 位的存储池所需要的能量，从字面上讲，比煮沸海洋需要的还多。”

如何安装 ZFS？

如果你想立刻使用 ZFS（开箱即用），那么你需要安装 FreeBSD 或一个使用 illumos 内核的操作系统。illumos 是 OpenSolaris 内核的一个克隆版本。

事实上，支持 ZFS 是一些有经验的 Linux 用户选择 BSD 的主要原因。

如果你想在 Linux 上尝试 ZFS，那么只能在存储文件系统上使用。据我所知，没有任何 Linux 发行版可以在根目录上安装 ZFS，实现开箱即用。如果你对在 Linux 上尝试 ZFS 感兴趣，那么 ZFS on Linux 项目 上有大量的教程可以指导你怎么做。

附加说明

这篇文章论述了 ZFS 的优点。现在，让我来告诉你一个关于 ZFS 很现实的问题。使用 RAID-Z 会很贵，因为你需要购买大量的磁盘来增大存储空间。

你已经使用过 ZFS 了吗？你的使用经验是什么样的？请在下面的评论中告诉我们。

如果你觉得这篇文章有趣，请花一分钟的时间把它分享到社交媒体、极客新闻或 Reddit 。

via: https://itsfoss.com/what-is-zfs/

作者：John Paul 选题：lujun9972 译者：ucasFL 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解 ext4 的历史，包括其与 ext3 和之前的其它文件系统之间的区别。

目前的大部分 Linux 文件系统都默认采用 ext4 文件系统，正如以前的 Linux 发行版默认使用 ext3、ext2 以及更久前的 ext。

对于不熟悉 Linux 或文件系统的朋友而言，你可能不清楚 ext4 相对于上一版本 ext3 带来了什么变化。你可能还想知道在一连串关于替代的文件系统例如 Btrfs、XFS 和 ZFS 不断被发布的情况下，ext4 是否仍然能得到进一步的发展。

在一篇文章中，我们不可能讲述文件系统的所有方面，但我们尝试让你尽快了解 Linux 默认文件系统的发展历史，包括它的诞生以及未来发展。

我仔细研究了维基百科里的各种关于 ext 文件系统文章、kernel.org 的 wiki 中关于 ext4 的条目以及结合自己的经验写下这篇文章。

ext 简史

MINIX 文件系统

在有 ext 之前，使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史，那么可以理解为 MINIX 是用于 IBM PC/AT 微型计算机的一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它，并于 1987 年发布了源代码（以印刷版的格式！）。

IBM 1980 中期的 PC/AT，MBlairMartin，CC BY-SA 4.0

虽然你可以细读 MINIX 的源代码，但实际上它并不是自由开源软件（FOSS）。出版 Tannebaum 著作的出版商要求你花 69 美元的许可费来运行 MINIX，而这笔费用包含在书籍的费用中。尽管如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 的安装在世界各个大学里面非常流行。而此时，年轻的 Linus Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布，而后在 1992 年 12 月在 GPL 开源协议下发布。

但是等等，这是一篇以 文件系统 为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。跟 MINIX 一样，Linux 的文件系统也如同玩具那般小 —— MINIX 文件系统最多能处理 14 个字符的文件名，并且只能处理 64MB 的存储空间。到了 1991 年，一般的硬盘尺寸已经达到了 40-140 MB。很显然，Linux 需要一个更好的文件系统。

ext

当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 从事第一代的 ext 文件系统的开发工作。ext 文件系统在 1992 年首次实现并发布 —— 仅在 Linux 首次发布后的一年！—— ext 解决了 MINIX 文件系统中最糟糕的问题。

1992 年的 ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2 GB 存储空间并处理 255 个字符的文件名。

但 ext 并没有长时间占统治地位，主要是由于它原始的时间戳（每个文件仅有一个时间戳，而不是今天我们所熟悉的有 inode、最近文件访问时间和最新文件修改时间的时间戳。）仅仅一年后，ext2 就替代了它。

ext2

Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。当 ext 仍然根植于 “玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。

ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOS 和 Windows。

但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。

尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 —— 最常见的是，作为便携式 USB 驱动器的文件系统格式。

ext3

1998 年，在 ext2 被采用后的 6 年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月在 2.4.15 内核版本中被采用到 Linux 内核主线中。

20 世纪 90 年代中期的 Packard Bell 计算机，Spacekid，CC0

在大部分情况下，ext2 在 Linux 发行版中工作得很好，但像 FAT、FAT32、HFS 和当时的其它文件系统一样 —— 在断电时容易发生灾难性的破坏。如果在将数据写入文件系统时候发生断电，则可能会将其留在所谓 不一致 的状态 —— 事情只完成一半而另一半未完成。这可能导致大量文件丢失或损坏，这些文件与正在保存的文件无关甚至导致整个文件系统无法卸载。

ext3 和 20 世纪 90 年代后期的其它文件系统，如微软的 NTFS，使用 日志 来解决这个问题。日志是磁盘上的一种特殊的分配区域，其写入被存储在事务中；如果该事务完成磁盘写入，则日志中的数据将提交给文件系统自身。如果系统在该操作提交前崩溃，则重新启动的系统识别其为未完成的事务而将其进行回滚，就像从未发生过一样。这意味着正在处理的文件可能依然会丢失，但文件系统 本身 保持一致，且其它所有数据都是安全的。

在使用 ext3 文件系统的 Linux 内核中实现了三个级别的日志记录方式： 日记 journal 、 顺序 ordered 和 回写 writeback 。

• 日记 是最低风险模式，在将数据和元数据提交给文件系统之前将其写入日志。这可以保证正在写入的文件与整个文件系统的一致性，但其显著降低了性能。
• 顺序 是大多数 Linux 发行版默认模式；顺序模式将元数据写入日志而直接将数据提交到文件系统。顾名思义，这里的操作顺序是固定的：首先，元数据提交到日志；其次，数据写入文件系统，然后才将日志中关联的元数据更新到文件系统。这确保了在发生崩溃时，那些与未完整写入相关联的元数据仍在日志中，且文件系统可以在回滚日志时清理那些不完整的写入事务。在顺序模式下，系统崩溃可能导致在崩溃期间文件的错误被主动写入，但文件系统它本身 —— 以及未被主动写入的文件 —— 确保是安全的。
• 回写 是第三种模式 —— 也是最不安全的日志模式。在回写模式下，像顺序模式一样，元数据会被记录到日志，但数据不会。与顺序模式不同，元数据和数据都可以以任何有利于获得最佳性能的顺序写入。这可以显著提高性能，但安全性低很多。尽管回写模式仍然保证文件系统本身的安全性，但在崩溃或崩溃之前写入的文件很容易丢失或损坏。

跟之前的 ext2 类似，ext3 使用 16 位内部寻址。这意味着对于有着 4K 块大小的 ext3 在最大规格为 16 TiB 的文件系统中可以处理的最大文件大小为 2 TiB。

ext4

Theodore Ts'o（是当时 ext3 主要开发人员）在 2006 年发表的 ext4，于两年后在 2.6.28 内核版本中被加入到了 Linux 主线。

Ts'o 将 ext4 描述为一个显著扩展 ext3 但仍然依赖于旧技术的临时技术。他预计 ext4 终将会被真正的下一代文件系统所取代。

Dell Precision 380 工作站，Lance Fisher，CC BY-SA 2.0

ext4 在功能上与 ext3 在功能上非常相似，但支持大文件系统，提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。

ext4 vs ext3

ext3 和 ext4 有一些非常明确的差别，在这里集中讨论下。

向后兼容性

ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件系统原地升级到 ext4；也允许 ext4 驱动程序以 ext3 模式自动挂载 ext3 文件系统，因此使它无需单独维护两个代码库。

大文件系统

ext3 文件系统使用 32 位寻址，这限制它仅支持 2 TiB 文件大小和 16 TiB 文件系统系统大小（这是假设在块大小为 4 KiB 的情况下，一些 ext3 文件系统使用更小的块大小，因此对其进一步被限制）。

ext4 使用 48 位的内部寻址，理论上可以在文件系统上分配高达 16 TiB 大小的文件，其中文件系统大小最高可达 1000000 TiB（1 EiB）。在早期 ext4 的实现中有些用户空间的程序仍然将其限制为最大大小为 16 TiB 的文件系统，但截至 2011 年，e2fsprogs 已经直接支持大于 16 TiB 大小的 ext4 文件系统。例如，红帽企业 Linux 在其合同上仅支持最高 50 TiB 的 ext4 文件系统，并建议 ext4 卷不超过 100 TiB。

分配方式改进

ext4 在将存储块写入磁盘之前对存储块的分配方式进行了大量改进，这可以显著提高读写性能。

区段

区段 extent 是一系列连续的物理块 (最多达 128 MiB，假设块大小为 4 KiB），可以一次性保留和寻址。使用区段可以减少给定文件所需的 inode 数量，并显著减少碎片并提高写入大文件时的性能。

多块分配

ext3 为每一个新分配的块调用一次块分配器。当多个写入同时打开分配器时，很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。

持久的预分配

在为文件预分配磁盘空间时，大部分文件系统必须在创建时将零写入该文件的块中。ext4 允许替代使用 fallocate()，它保证了空间的可用性（并试图为它找到连续的空间），而不需要先写入它。这显著提高了写入和将来读取流和数据库应用程序的写入数据的性能。

延迟分配

这是一个耐人寻味而有争议性的功能。延迟分配允许 ext4 等待分配将写入数据的实际块，直到它准备好将数据提交到磁盘。（相比之下，即使数据仍然在往写入缓存中写入，ext3 也会立即分配块。）

当缓存中的数据累积时，延迟分配块允许文件系统对如何分配块做出更好的选择，降低碎片（写入，以及稍后的读）并显著提升性能。然而不幸的是，它 增加 了还没有专门调用 fsync() 方法（当程序员想确保数据完全刷新到磁盘时）的程序的数据丢失的可能性。

假设一个程序完全重写了一个文件：

fd=open("file", O_TRUNC); write(fd, data); close(fd);

使用旧的文件系统，close(fd); 足以保证 file 中的内容刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。

如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和较新版本都可能丢失数据或损坏。如果其它进程在写入文件时访问文件，则会看到损坏的版本。如果其它进程打开文件并且不希望其内容发生更改 —— 例如，映射到多个正在运行的程序的共享库。这些进程可能会崩溃。

为了避免这些问题，一些程序员完全避免使用 O_TRUNC。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件名：

fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");

在 没有 延迟分配的文件系统下，这足以避免上面列出的潜在的损坏和崩溃问题：因为 rename() 是原子操作，所以它不会被崩溃中断；并且运行的程序将继续引用旧的文件。现在 file 的未链接版本只要有一个打开的文件文件句柄即可。但是因为 ext4 的延迟分配会导致写入被延迟和重新排序，rename("newfile", "file") 可以在 newfile 的内容实际写入磁盘内容之前执行，这出现了并行进行再次获得 file 坏版本的问题。

为了缓解这种情况，Linux 内核（自版本 2.6.30）尝试检测这些常见代码情况并强制立即分配。这会减少但不能防止数据丢失的可能性 —— 并且它对新文件没有任何帮助。如果你是一位开发人员，请注意：保证数据立即写入磁盘的唯一方法是正确调用 fsync()。

无限制的子目录

ext3 仅限于 32000 个子目录；ext4 允许无限数量的子目录。从 2.6.23 内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。

日志校验

ext3 没有对日志进行校验，这给处于内核直接控制之外的磁盘或自带缓存的控制器设备带来了问题。如果控制器或具自带缓存的磁盘脱离了写入顺序，则可能会破坏 ext3 的日记事务顺序，从而可能破坏在崩溃期间（或之前一段时间）写入的文件。

理论上，这个问题可以使用写入 障碍 barrier —— 在安装文件系统时，你在挂载选项设置 barrier=1，然后设备就会忠实地执行 fsync 一直向下到底层硬件。通过实践，可以发现存储设备和控制器经常不遵守写入障碍 —— 提高性能（和跟竞争对手比较的性能基准），但增加了本应该防止数据损坏的可能性。

对日志进行校验和允许文件系统崩溃后第一次挂载时意识到其某些条目是无效或无序的。因此，这避免了回滚部分条目或无序日志条目的错误，并进一步损坏的文件系统 —— 即使部分存储设备假做或不遵守写入障碍。

快速文件系统检查

在 ext3 下，在 fsck 被调用时会检查整个文件系统 —— 包括已删除或空文件。相比之下，ext4 标记了 inode 表未分配的块和扇区，从而允许 fsck 完全跳过它们。这大大减少了在大多数文件系统上运行 fsck 的时间，它实现于内核 2.6.24。

改进的时间戳

ext3 提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。ext4 通过提供纳秒级的时间戳，使其可用于那些企业、科学以及任务关键型的应用程序。

ext3 文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。ext4 在这里增加了两个位，将 Unix 纪元扩展了 408 年。如果你在公元 2446 年读到这篇文章，你很有可能已经转移到一个更好的文件系统 —— 如果你还在测量自 1970 年 1 月 1 日 00:00（UTC）以来的时间，这会让我死后得以安眠。

在线碎片整理

ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。ext2 有一个包含的实用程序 e2defrag，它的名字暗示 —— 它需要在文件系统未挂载时脱机运行。（显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 —— 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 e2defrag 可能会导致灾难性损坏和数据丢失。

尽管 ext3 最初被认为“不受碎片影响”，但对同一文件（例如 BitTorrent）采用大规模并行写入过程的过程清楚地表明情况并非完全如此。一些用户空间的手段和解决方法，例如 Shake，以这样或那样方式解决了这个问题 —— 但它们比真正的、文件系统感知的、内核级碎片整理过程更慢并且在各方面都不太令人满意。

ext4 通过 e4defrag 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和区段级别的碎片整理实用程序。

正在进行的 ext4 开发

ext4，正如 Monty Python 中瘟疫感染者曾经说过的那样，“我还没死呢！”虽然它的主要开发人员认为它只是一个真正的下一代文件系统的权宜之计，但是在一段时间内，没有任何可能的候选人准备好（由于技术或许可问题）部署为根文件系统。

在未来的 ext4 版本中仍然有一些关键功能要开发，包括元数据校验和、一流的配额支持和大分配块。

元数据校验和

由于 ext4 具有冗余超级块，因此为文件系统校验其中的元数据提供了一种方法，可以自行确定主超级块是否已损坏并需要使用备用块。可以在没有校验和的情况下，从损坏的超级块恢复 —— 但是用户首先需要意识到它已损坏，然后尝试使用备用方法手动挂载文件系统。由于在某些情况下，使用损坏的主超级块安装文件系统读写可能会造成进一步的损坏，即使是经验丰富的用户也无法避免，这也不是一个完美的解决方案！

与 Btrfs 或 ZFS 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和的功能非常弱。但它总比没有好。虽然校验 所有的事情 都听起来很简单！—— 事实上，将校验和与文件系统连接到一起有一些重大的挑战；请参阅设计文档了解详细信息。

一流的配额支持

等等，配额？！从 ext2 出现的那天开始我们就有了这些！是的，但它们一直都是事后的添加的东西，而且它们总是犯傻。这里可能不值得详细介绍，但设计文档列出了配额将从用户空间移动到内核中的方式，并且能够更加正确和高效地执行。

大分配块

随着时间的推移，那些讨厌的存储系统不断变得越来越大。由于一些固态硬盘已经使用 8K 硬件块大小，因此 ext4 对 4K 模块的当前限制越来越受到限制。较大的存储块可以显著减少碎片并提高性能，代价是增加“松弛”空间（当你只需要块的一部分来存储文件或文件的最后一块时留下的空间）。

你可以在设计文档中查看详细说明。

ext4 的实际限制

ext4 是一个健壮、稳定的文件系统。如今大多数人都应该在用它作为根文件系统，但它无法处理所有需求。让我们简单地谈谈你不应该期待的一些事情 —— 现在或可能在未来：

虽然 ext4 可以处理高达 1 EiB 大小（相当于 1,000,000 TiB）大小的数据，但你 真的 不应该尝试这样做。除了能够记住更多块的地址之外，还存在规模上的问题。并且现在 ext4 不会处理（并且可能永远不会）超过 50-100 TiB 的数据。

ext4 也不足以保证数据的完整性。随着日志记录的重大进展又回到了 ext3 的那个时候，它并未涵盖数据损坏的许多常见原因。如果数据已经在磁盘上被破坏 —— 由于故障硬件，宇宙射线的影响（是的，真的），或者只是数据随时间衰减 —— ext4 无法检测或修复这种损坏。

基于上面两点，ext4 只是一个纯 文件系统，而不是存储卷管理器。这意味着，即使你有多个磁盘 —— 也就是奇偶校验或冗余，理论上你可以从 ext4 中恢复损坏的数据，但无法知道使用它是否对你有利。虽然理论上可以在不同的层中分离文件系统和存储卷管理系统而不会丢失自动损坏检测和修复功能，但这不是当前存储系统的设计方式，并且它将给新设计带来重大挑战。

备用文件系统

在我们开始之前，提醒一句：要非常小心，没有任何备用的文件系统作为主线内核的一部分而内置和直接支持！

即使一个文件系统是 安全的，如果在内核升级期间出现问题，使用它作为根文件系统也是非常可怕的。如果你没有充分的理由通过一个 chroot 去使用替代介质引导，耐心地操作内核模块、grub 配置和 DKMS……不要在一个很重要的系统中去掉预留的根文件。

可能有充分的理由使用你的发行版不直接支持的文件系统 —— 但如果你这样做，我强烈建议你在系统启动并可用后再安装它。（例如，你可能有一个 ext4 根文件系统，但是将大部分数据存储在 ZFS 或 Btrfs 池中。）

XFS

XFS 与非 ext 文件系统在 Linux 中的主线中的地位一样。它是一个 64 位的日志文件系统，自 2001 年以来内置于 Linux 内核中，为大型文件系统和高度并发性提供了高性能（即大量的进程都会立即写入文件系统）。

从 RHEL 7 开始，XFS 成为 Red Hat Enterprise Linux 的默认文件系统。对于家庭或小型企业用户来说，它仍然有一些缺点 —— 最值得注意的是，重新调整现有 XFS 文件系统是一件非常痛苦的事情，不如创建另一个并复制数据更有意义。

虽然 XFS 是稳定的且是高性能的，但它和 ext4 之间没有足够具体的最终用途差异，以值得推荐在非默认（如 RHEL7）的任何地方使用它，除非它解决了对 ext4 的特定问题，例如大于 50 TiB 容量的文件系统。

XFS 在任何方面都不是 ZFS、Btrfs 甚至 WAFL（一个专有的 SAN 文件系统）的“下一代”文件系统。就像 ext4 一样，它应该被视为一种更好的方式的权宜之计。

ZFS

ZFS 由 Sun Microsystems 开发，以 zettabyte 命名 —— 相当于 1 万亿 GB —— 因为它理论上可以解决大型存储系统。

作为真正的下一代文件系统，ZFS 提供卷管理（能够在单个文件系统中处理多个单独的存储设备），块级加密校验和（允许以极高的准确率检测数据损坏），自动损坏修复（其中冗余或奇偶校验存储可用），快速异步增量复制，内联压缩等，以及更多。

从 Linux 用户的角度来看，ZFS 的最大问题是许可证问题。ZFS 许可证是 CDDL 许可证，这是一种与 GPL 冲突的半许可的许可证。关于在 Linux 内核中使用 ZFS 的意义存在很多争议，其争议范围从“它是 GPL 违规”到“它是 CDDL 违规”到“它完全没问题，它还没有在法庭上进行过测试。”最值得注意的是，自 2016 年以来 Canonical 已将 ZFS 代码内联在其默认内核中，而且目前尚无法律挑战。

此时，即使我作为一个非常狂热于 ZFS 的用户，我也不建议将 ZFS 作为 Linux 的根文件系统。如果你想在 Linux 上利用 ZFS 的优势，用 ext4 设置一个小的根文件系统，然后将 ZFS 用在你剩余的存储上，把数据、应用程序以及你喜欢的东西放在它上面 —— 但把 root 分区保留在 ext4 上，直到你的发行版明确支持 ZFS 根目录。

Btrfs

Btrfs 是 B-Tree Filesystem 的简称，通常发音为 “butter” —— 由 Chris Mason 于 2007 年在 Oracle 任职期间发布。Btrfs 旨在跟 ZFS 有大部分相同的目标，提供多种设备管理、每块校验、异步复制、直列压缩等，还有更多。

截至 2018 年，Btrfs 相当稳定，可用作标准的单磁盘文件系统，但可能不应该依赖于卷管理器。与许多常见用例中的 ext4、XFS 或 ZFS 相比，它存在严重的性能问题，其下一代功能 —— 复制、多磁盘拓扑和快照管理 —— 可能非常多，其结果可能是从灾难性地性能降低到实际数据的丢失。

Btrfs 的维持状态是有争议的；SUSE Enterprise Linux 在 2015 年采用它作为默认文件系统，而 Red Hat 于 2017 年宣布它从 RHEL 7.4 开始不再支持 Btrfs。可能值得注意的是，该产品支持 Btrfs 部署用作单磁盘文件系统，而不是像 ZFS 中的多磁盘卷管理器，甚至 Synology 在它的存储设备使用 Btrfs，但是它在传统 Linux 内核 RAID（mdraid）之上分层来管理磁盘。

via: https://opensource.com/article/18/4/ext4-filesystem

作者：Jim Salter 译者：HardworkFish 校对：wxy, pityonline

本文由 LCTT 原创编译，Linux中国 荣誉推出