Fedora 33 在其各类桌面版本中引入了新的默认文件系统 Btrfs。多年以来，Fedora 一直在 逻辑卷管理 Logical Volume Manager （LVM） 卷之上使用 ext4，引入 Brtfs 对 Fedora 来说是一个很大的转变。更改默认文件系统需要 令人信服的原因。虽然 Btrfs 是令人兴奋的下一代文件系统，但 LVM 上的 ext4 是成熟而稳定的。本指南旨在探索各自的高级特性，使得更容易在 Btrfs 和 LVM-ext4 之间进行选择。先说结论最简单的建议是坚持使用默认值。全新安装的 Fedora 33 环境默认为 Btrfs，升级之前的 Fedora 版本将继续使用最初安装的设置，通常是 LVM-ext4。对于现有的 Fedora 用户来说，获取 Btrfs 的最简单方式是全新安装。然而，全新安装比简单升级更具破坏性。除非有特殊需要，否则这种干扰可能是不必要的。Fedora 开发团队仔细考虑了这两个默认值，因此对任何一个选择都要有信心。那么其他文件系统呢？现在有很多 Linux 系统的文件系统。在加上卷管理器、加密方法和存储机制的组合后，这一数字呈爆炸式增长。那么，为什么要关注 btrfs 和 LVM-ext4 呢？对于 Fedora 的用户来说，这两种设置可能是最常见的。在 Fedora 11 中，LVM 之上的 ext4 成为了默认磁盘布局，在此之前则使用的是 ext3。既然 Btrfs 是 Fedora 33 的默认设置，那么绝大多数现有用户会考虑是应该原地踏步还是向前跳跃。面对全新安装的 Fedora 33 环境，有经验的 Linux 用户可能会想知道是使用这个新的文件系统，还是退回到他们熟悉的文件系统。因此，在众多可能的存储选项中，许多 Fedora 用户会想知道如何在 Btrfs 和 LVM-ext4 之间进行选择。两者的共性尽管两个文件系统之间存在核心差异，但 Btrfs 和 LVM-ext4 实际上有很多共同之处。两者都是成熟且经过充分测试的存储技术。从 Fedora Core 的早期开始，就一直在使用 LVM，而 ext4 在 2009 年成为 Fedora 11 的默认设置。Btrfs 在 2009 年并入 Linux 主线内核，并且 Facebook 广泛使用了该文件系统。SUSE Linux Enterprise 12 在 2014 年使其成为默认文件系统。因此，它在生产环境中也有着长久的运行时间。这两个系统都能很好地防止因意外停电而导致的文件系统损坏，尽管它们的实现方式不同。它们支持的配置包括使用单盘设置和跨越多个设备，并且这两种配置都能够创建近乎即时的快照。有各种工具可以帮助管理这两种系统，包括命令行和图形界面。这两种解决方案在家用台式机和高端服务器上都同样有效。LVM-ext4 的优势ext4 文件系统 专注于高性能和可伸缩性，没有太多额外的花哨之处。它能有效地防止长时间后的碎片化，并当碎片化出现后提供了 很好的工具。ext4 之所以坚如磐石，是因为它构建在前代的 ext3 文件系统之上，带来了多年的系统内测试和错误修复。LVM-ext4 环境中的大多数高级功能都来自 LVM 本身。LVM 位于文件系统的“下方”，这意味着它支持任何文件系统。 逻辑卷 Logical volume （LV）是通用的块设备，因此 虚拟机可以直接使用它们。这种灵活性使得每个逻辑卷都可以使用合适的文件系统，用合适的选项应对各种情况。这种分层方法还遵循了“小工具协同工作”的 Unix 哲学。从硬件抽象出来的 卷组 volume group （VG）允许 LVM 创建灵活的逻辑卷。每个逻辑卷都提取自同一个存储池，但具有自己的设置。调整卷的大小比调整物理分区的大小容易得多，因为没有数据有序放置的限制。LVM 物理卷 physical volume （PV）可以是任意数量的分区，甚至可以在系统运行时在设备之间移动。LVM 支持只读和读写的 快照，这使得从活动系统创建一致的备份变得很容易。每个快照都有一个定义的大小，更改源卷或快照卷将占用其中的空间。又或者，逻辑卷也可以是 稀疏配置池 thinly provisioned pool 的一部分。这允许快照自动使用池中的数据，而不是使用在创建卷时定义的固定大小的块。有多个磁盘驱动器的 LVM当有多个设备时，LVM 才真正大放异彩。它原生支持大多数 RAID 级别，每个逻辑卷可以具有不同的 RAID 级别。LVM 将自动为 RAID 配置选择适当的物理设备，或者用户可以直接指定它。基本的 RAID 支持包括用于性能的数据条带化（RAID0）和用于冗余的镜像（RAID1）。逻辑卷也可以使用 RAID5、RAID6 和 RAID10 等高级设置。LVM RAID 支持已经成熟，因为 LVM 在底层使用的 设备映射器（dm） 和 多设备（md） 内核支持， 与 mdadm 使用的一样。对于具有快速和慢速驱动器的系统，逻辑卷也可以是 缓存卷。经典示例是 SSD 和传统磁盘驱动器的组合。缓存卷使用较快的驱动器来存储更频繁访问的数据（或用作写缓存），而慢速的驱动器则用于处理大量数据。LVM 中大量稳定的功能以及 ext4 的可靠性在既往的使用中早已被证明了。当然，功能越多就越复杂。在配置 LVM 时，要找到合适的功能选项是很有挑战性的。对于单驱动器的台式机系统，LVM 的功能（例如 RAID 和缓存卷）不适用。但是，逻辑卷比物理分区更灵活，快照也很有用。对于正常的桌面使用，LVM 的复杂性会成为典型的用户可能遇到的问题恢复的障碍。Btrfs 的优势从前几代文件系统中学到的经验指导了构建到 Btrfs 的功能设计。与 ext4 不同，它可以直接跨越多个设备，因此它具有通常仅在卷管理器中才能找到的功能。它还具有 Linux 文件系统空间中独有的功能（ZFS 具有相似的功能集，但不要指望它在 Linux 内核中出现）。Btrfs 的主要功能也许最重要的功能是对所有数据进行 校验和 checksumming 。校验和与 写时复制 copy-on-write （COW）一起，提供了在意外断电后确保文件系统完整性的 关键方法。更独特的是，校验和可以检测数据本身中的错误。悄然的数据损坏（有时也称为 bitrot）比大多数人意识到的更常见。如果没有主动验证，损坏最终可能会传播到所有可用的备份中。这使得用户没有有效的副本。通过透明地校验所有数据，Btrfs 能够立即检测到任何此类损坏。启用正确的 dup 或 raid 选项，文件系统也可以透明地修复损坏。写时复制也是 Btrfs 的基本功能，因为它在提供文件系统完整性和即时子卷快照方面至关重要。从公共子卷创建快照后，快照会自动共享底层数据。另外，事后的 重复数据删除 deduplication 使用相同的技术来消除相同的数据块。单个文件可以通过使用 cp 的 reflink 选项 来使用 COW 功能。reflink 副本对于复制大型文件（例如虚拟机镜像）特别有用，这些文件往往随着时间的推移具有大部分相同的数据。Btrfs 支持跨越多个设备，而无需卷管理器。多设备支持可提供数据镜像功能以实现冗余和条带化以提高性能。此外，还实验性地支持更高级的 RAID 级别，例如 RAID 5 和 RAID 6。与标准 RAID 设置不同，Btrfs 的 RAID1 实际上允许奇数个设备。例如，它可以使用 3 个设备，即使它们的大小不同。所有 RAID 和 dup 选项都是在文件系统级别指定的。因此，各个子卷不能使用不同的选项。请注意，使用多设备的 RAID1 选项意味着即使一个设备发生故障，卷中的所有数据都是可用的，并且校验功能可以保持数据本身的完整性。这超出了当前典型的 RAID 设置所能提供的范围。附加功能Btrfs 还支持快速简便的远程备份。子卷快照可以 发送到远程系统 进行存储。通过利用文件系统中固有的 COW 元数据，这些传输通过仅发送先前发送的快照中的增量更改而非常有效。诸如 snapper 之类的用户应用程序使管理这些快照变得容易。另外，Btrfs 卷可以具有 透明压缩 功能，并且 chattr +c 可以标记进行压缩的单个文件或目录。压缩不仅可以减少数据消耗的空间，还可以通过减少写入操作量来帮助延长 SSD 的寿命。压缩当然会带来额外的 CPU 开销，但是有很多选项就可以权衡取舍。Btrfs 集成了文件系统和卷管理器功能，这意味着总体维护比 LVM-ext4 更简单。当然，这种集成的灵活性较低，但是对于大多数台式机甚至服务器而言，设置已足够。LVM 上使用 BtrfsBtrfs 可以 就地转换 ext3/ext4 文件系统。就地转换意味着无需将数据复制出来然后再复制回去。数据块本身甚至都不需要修改。因此，对于现有的 LVM-ext4 系统，一种选择是将 LVM 保留在原处，然后简单地将 ext4 转换为 Btrfs。虽然可行且受支持，但有一些原因使它不是最佳选择。Btrfs 的吸引力之一是与卷管理器集成的文件系统所带来的更轻松的管理。要是在 LVM 之上运行，对于系统维护，仍然要对额外的卷管理器进行一些设置。同样，LVM 设置通常具有多个固定大小的逻辑卷，并具有独立文件系统。虽然 Btrfs 支持给定的计算机上的多个卷，但是许多不错的功能都需要单一卷具有多个子卷。如果每个 LVM 卷都有一个独立的 Btrfs 卷，则用户仍然需要手动管理固定大小的 LVM 卷。虽然能够收缩挂载的 Btrfs 文件系统的能力确实使处理固定大小的卷的工作变得更轻松。通过在线收缩功能，就无需启动 实时镜像 了。在使用 Btrfs 的多设备支持时，必须仔细考虑逻辑卷的物理位置。对于 Btrfs 而言，每个逻辑卷都是一个单独的物理设备，如果实际情况并非如此，则某些数据可用性功能可能会做出错误的决定。例如，如果单个驱动器发生故障，对数据使用 RAID1 通常可以提供保护。如果实际逻辑卷在同一物理设备上，则没有冗余。如果强烈需要某些特定的 LVM 功能，例如原始块设备或高速缓存的逻辑卷，则在 LVM 之上运行 Btrfs 是有意义的。在这种配置下，Btrfs 仍然提供其大多数优点，例如校验和和易于发送的增量快照。尽管使用 LVM 会产生一些操作开销，但 Btrfs 的这种开销并不比任何其他文件系统大。总结当尝试在 Btrfs 和 LVM-ext4 之间进行选择时，没有一个正确的答案。每个用户都有独特的要求，并且同一用户可能拥有具有不同需求的不同系统。看一下每个配置的功能集，并确定是否有令人心动的功能。如果没有，坚持默认值没有错。选择这两种设置都有很好的理由。via: https://fedoramagazine.org/choose-between-btrfs-and-lvm-ext4/作者：Troy Curtis Jr 选题：lujun9972 译者：Chao-zhi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Dropbox 在 Linux 上终止除了 Ext4 之外所有文件系统的同步支持
Dropbox 正考虑将同步支持限制为少数几种文件系统类型：Windows 的 NTFS、macOS 的 HFS+/APFS 和 Linux 的 Ext4。Dropbox 是最受欢迎的 Linux 中的云服务之一。很多人都在使用 Linux 下的 Dropbox 同步客户端。但是，最近，一些用户在他们的 Dropbox Linux 桌面客户端上收到一条警告说：“移动 Dropbox 文件夹位置， Dropbox 将在 11 月停止同步“Dropbox 将仅支持少量文件系统一个 Reddit 主题强调了一位用户在 Dropbox 论坛上查询了该消息后的公告，该消息被社区管理员标记为意外新闻。这是回复中的内容：“大家好，在 2018 年 11 月 7 日，我们会结束 Dropbox 在某些不常见文件系统的同步支持。支持的文件系统是 Windows 的 NTFS、macOS 的 HFS+ 或 APFS，以及Linux 的 Ext4。Dropbox 官方论坛Dropbox 官方确认支持文件系统的限制此举旨在提供稳定和一致的体验。Dropbox 还更新了其桌面要求。那你该怎么办？如果你在不受支持的文件系统上使用 Dropbox 进行同步，那么应该考虑更改位置。Linux 仅支持 Ext4 文件系统。但这并不是一个令人担忧的新闻，因为你可能已经在使用 Ext4 文件系统了。在 Ubuntu 或其他基于 Ubuntu 的发行版上，打开磁盘应用并查看 Linux 系统所在分区的文件系统。检查 Ubuntu 上的文件系统类型如果你的系统上没有安装磁盘应用，那么可以使用命令行了解文件系统类型。如果你使用的是 Ext4 文件系统并仍然收到来自 Dropbox 的警告，请检查你是否有可能收到通知的非活动计算机/设备。如果是，将该系统与你的 Dropbox 帐户取消连接。Dropbox 也不支持加密的 Ext4 吗？一些用户还报告说他们在加密 Ext4 文件系统同步时也收到了警告。那么，这是否意味着 Linux 的 Dropbox 客户端只支持未加密的 Ext4 文件系统？这方面 Dropbox 没有官方声明。你使用的是什么文件系统？你也收到了警告吗？如果你在收到警告后仍不确定该怎么做，你应该前往该方案的官方帮助中心页面。请在下面的评论中告诉我们你的想法。via: https://itsfoss.com/dropbox-linux-ext4-only/作者：Ankush Das 选题：lujun9972 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
如何在 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=orderedfindmnt 还可以生成 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 findmntfindmnt 命令已足够完成在 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中国 荣誉推出
了解 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 就替代了它。ext2Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。当 ext 仍然根植于 “玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOS 和 Windows。但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 —— 最常见的是，作为便携式 USB 驱动器的文件系统格式。ext31998 年，在 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。ext4Theodore Ts'o（是当时 ext3 主要开发人员）在 2006 年发表的 ext4，于两年后在 2.6.28 内核版本中被加入到了 Linux 主线。Ts'o 将 ext4 描述为一个显著扩展 ext3 但仍然依赖于旧技术的临时技术。他预计 ext4 终将会被真正的下一代文件系统所取代。Dell Precision 380 工作站，Lance Fisher，CC BY-SA 2.0ext4 在功能上与 ext3 在功能上非常相似，但支持大文件系统，提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。ext4 vs ext3ext3 和 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 池中。）XFSXFS 与非 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 一样，它应该被视为一种更好的方式的权宜之计。ZFSZFS 由 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 根目录。BtrfsBtrfs 是 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中国 荣誉推出
Linux 的 EXT4 文件系统的历史、特性以及最佳实践
让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的几代 EXT 文件系统有何不同。在之前关于 Linux 文件系统的文章里，我写过一篇 Linux 文件系统介绍 和一些更高级的概念例如 一切都是文件。现在我想要更深入地了解 EXT 文件系统的特性的详细内容，但是首先让我们来回答一个问题，“什么样才算是一个文件系统 ？” 一个文件系统应该涵盖以下所有特点：数据存储： 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个结构化的容器来存储和获取数据。命名空间： 命名空间是一个提供了用于命名与组织数据的命名规则和数据结构的方法学。安全模型： 一个用于定义访问权限的策略。API： 操作这个系统的对象的系统功能调用，这些对象诸如目录和文件。实现： 能够实现以上几点的软件。本文内容的讨论主要集中于上述几点中的第一项，并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。EXT 文件系统历史虽然 EXT 文件系统是为 Linux 编写的，但其真正起源于 Minix 操作系统和 Minix 文件系统，而 Minix 最早发布于 1987，早于 Linux 5 年。如果我们从 EXT 文件系统大家族的 Minix 起源来观察其历史与技术发展那么理解 EXT4 文件系统就会简单得多。Minix当 Linux Torvalds 在写最初的 Linux 内核的时候，他需要一个文件系统但是他又不想自己写一个。于是他简单地把 Minix 文件系统 加了进去，这个 Minix 文件系统是由 Andrew S. Tanenbaum 写的，同时它也是 Tanenbaum 的 Minix 操作系统的一部分。Minix 是一个类 Unix 风格的操作系统，最初编写它的原因是用于教育用途。Minix 的代码是自由可用的并有适当的许可协议，所以 Torvalds 可以把它用 Linux 的最初版本里。Minix 有以下这些结构，其中的大部分位于生成文件系统的分区中：引导扇区 是硬盘安装后的第一个扇区。这个引导块包含了一个非常小的引导记录和一个分区表。每一个分区的第一个块都是一个包含了元数据的 超级块 （ superblock ） ，这些元数据定义了其他的文件系统结构并将其定位于物理硬盘的具体分区上。一个 inode 位图块 决定了哪些 inode 是在使用中的，哪一些是未使用的。inode 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息，包括其所处的数据块的位置，也就是该文件所处的区域。一个 区位图 用于保持追踪数据区域的使用和未使用情况。一个 数据区, 这里是数据存储的地方。对上述了两种位图类型来说，一个 位 （ bit ） 表示一个指定的数据区或者一个指定的 inode。 如果这个位是 0 则表示这个数据区或者这个 inode 是未使用的，如果是 1 则表示正在使用中。那么，inode 又是什么呢 ? 就是 index-node（索引节点）的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。同时，这个 inode 还包含了位置数据，指向了其所对应的文件数据在硬盘中的位置。在 Minix 和 EXT 1-3 文件系统中，这是一个数据区和块的列表。Minix 文件系统的 inode 支持 9 个数据块，包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 Minix 文件系统结构 。同时你也可以在维基百科上对 inode 指针结构 做一个快速了解。EXT原生的 EXT 文件系统 (意即 扩展的 （ extended ） ) 是由 Rémy Card 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），其也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被确证的，显然这是因为其存在着严重的问题，并且它很快地被 EXT2 文件系统取代了。EXT2EXT2 文件系统 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 5.0 时接触的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多供将来使用的磁盘空间。和 Minix 类似，EXT2 也有一个引导扇区 ，它是硬盘安装后的第一个扇区。它包含了非常小的引导记录和一个分区表。接着引导扇区之后是一些保留的空间，它填充了引导记录和硬盘驱动器上的第一个分区（通常位于下一个柱面）之间的空间。GRUB2 - 也可能是 GRUB1 - 将此空间用于其部分引导代码。每个 EXT2 分区中的空间被分为 柱面组 （ cylinder group ） ，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为 8MB。 下面的图 1 显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为 4K。图 1： EXT 文件系统中的柱面组的结构柱面组中的第一个块是一个 超级块 （ superblock ） ，它包含了元数据，定义了其它文件系统的结构并将其定位于物理硬盘的具体分区上。分区中有一些柱面组还会有备用超级块，但并不是所有的柱面组都有。我们可以使用例如 dd 等磁盘工具来拷贝备用超级块的内容到主超级块上，以达到修复损坏的超级块的目的。虽然这种情况不会经常发生，但是在几年前我的一个超级块损坏了，我就是用这种方法来修复的。幸好，我很有先见之明地使用了 dumpe2fs 命令来备份了我的系统上的分区描述符信息。以下是 dumpe2fs 命令的一部分输出。这部分输出主要是超级块上包含的一些元数据，同时也是文件系统上的前两个柱面组的数据。# dumpe2fs /dev/sda1 Filesystem volume name: boot Last mounted on: /boot Filesystem UUID: 79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 122160 Block count: 488192 Reserved block count: 24409 Free blocks: 376512 Free inodes: 121690 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 238 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8144 Inode blocks per group: 509 Flex block group size: 16 Filesystem created: Tue Feb 7 09:33:34 2017 Last mount time: Sat Apr 29 21:42:01 2017 Last write time: Sat Apr 29 21:42:01 2017 Mount count: 25 Maximum mount count: -1 Last checked: Tue Feb 7 09:33:34 2017 Check interval: 0 (<none>) Lifetime writes: 594 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: c780bac9-d4bf-4f35-b695-0fe35e8d2d60 Journal backup: inode blocks Journal features: journal_64bit Journal size: 32M Journal length: 8192 Journal sequence: 0x00000213 Journal start: 0 Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-239 Block bitmap at 240 (+240) Inode bitmap at 255 (+255) Inode table at 270-778 (+270) 24839 free blocks, 7676 free inodes, 16 directories Free blocks: 7929-32767 Free inodes: 440, 470-8144 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-33007 Block bitmap at 241 (bg #0 + 241) Inode bitmap at 256 (bg #0 + 256) Inode table at 779-1287 (bg #0 + 779) 8668 free blocks, 8142 free inodes, 2 directories Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 Free inodes: 8147-16288 Group 2: (Blocks 65536-98303) Block bitmap at 242 (bg #0 + 242) Inode bitmap at 257 (bg #0 + 257) Inode table at 1288-1796 (bg #0 + 1288) 6326 free blocks, 8144 free inodes, 0 directories Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 Free inodes: 16289-24432 Group 3: (Blocks 98304-131071) <截断> 每一个柱面组都有自己的 inode 位图，用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了一个文件的相关信息，包括属于该文件的数据块的位置。而块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，柱面组的数据可以多达数百页的长度。柱面组的元数据包括组中所有空闲数据块的列表。EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。我所遇见的关于 EXT2 文件系统最大的问题是 fsck (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有的不一致性，从而导致在系统 崩溃 （ crash ） 后其会花费了数个小时来修复。有一次我的其中一台电脑在崩溃后重新启动时共花费了 28 个小时恢复磁盘，而且并且是在磁盘被检测量只有几百兆字节大小的情况下。EXT3EXT3 文件系统是应一个目标而生的，就是克服 fsck 程序需要完全恢复在文件更新操作期间发生的不正确关机而损坏的磁盘结构所需的大量时间。它对 EXT 文件系统的唯一新增功能就是 日志，它将提前记录将对文件系统执行的更改。 EXT3 的磁盘结构的其余部分与 EXT2 中的相同。除了同先前的版本一样直接写入数据到磁盘的数据区域外，EXT3 上的日志会将文件数据随同元数据写入到磁盘上的一个指定数据区域。一旦这些（日志）数据安全地到达硬盘，它就可以几乎零丢失率地被合并或被追加到目标文件上。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在日志中的所有数据提交之前，系统发生故障时文件系统将保持一致状态。在下次启动时，将检查文件系统的不一致性，然后将仍保留在日志中的数据提交到磁盘的数据区，以完成对目标文件的更新。日志功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性、安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。日志功能将失败后检查硬盘驱动器所需的时间从几小时（甚至几天）减少到了几分钟。 多年来，我遇到了很多导致我的系统崩溃的问题。要详细说的话恐怕还得再写一篇文章，但这里需要说明的是大多数是我自己造成的，就比如不小心踢掉电源插头。 幸运的是，EXT 日志文件系统将启动恢复时间缩短到两三分钟。此外，自从我开始使用带日志记录的 EXT3，我从来没有遇到丢失数据的问题。EXT3 的日志功能可以关闭，然后其功能就等同于 EXT2 文件系统了。 该日志本身仍然是存在的，只是状态为空且未使用。 只需在 mount 命令中使用文件系统类型参数来重新挂载即可指定为 EXT2。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，不过你也可以更改 /etc/fstab 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3 文件系统挂载为 EXT2 ，因为这会有丢失数据和增加恢复时间的潜在可能性。EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。tune2fs -j /dev/sda1 /dev/sda1 表示驱动器和分区的标识符。同时要注意修改 /etc/fstab 中的文件系统类型标识符并重新挂载分区，或者重启系统以确保修改生效。EXT4EXT4 文件系统主要提高了性能、可靠性和容量。为了提高可靠性，它新增了元数据和日志校验和。同时为了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳，并在时间戳字段中添加了两个高位来延缓时间戳的 2038 年问题 ，这样 EXT4 文件系统至少可用到 2446 年。在 EXT4 中，数据分配从固定块改为 扩展盘区 （ extent ） 方式，扩展盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理上连续的文件，这可以显著减少描述大文件中所有数据的位置所需的指针数。其它在 EXT4 中已经实施的分配策略可以进一步减少碎片化。EXT4 通过将新创建的文件散布在磁盘上，使其不会像早期的 PC 文件系统一样全部聚集在磁盘起始位置，从而减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地散布文件，并且当文件（由于太大）需要分段存储时，使不连续的文件扩展盘区尽可能靠近同一文件中的其他部分，以尽可能减少磁头寻道和电机旋转等待时间。当创建新文件或扩展现有文件时，使用其它策略来预先分配额外的磁盘空间。这有助于确保扩展文件时不会自动导致其分段。新文件不会紧挨这现有文件立即分配空间，这也可以防止现有文件的碎片化。除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集到所有正在写入磁盘的数据，这可以提高数据空间连续的可能性。较旧的 EXT 文件系统（如 EXT2 和 EXT3）可以作为 EXT4 进行 mount ，以使其性能获得较小的提升。但不幸的是，这需要关闭 EXT4 的一些重要的新功能，所以我建议不要这样做。自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。我们可以使用 Fedora 文档中描述的 流程 将 EXT3 文件系统升级到 EXT4，但是由于仍然存留的之前的 EXT3 元数据结构，它的性能仍将受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 mkfs 命令将空 EXT4 文件系统写入分区，然后从备份中恢复所有数据。Inode之前介绍过的 inode 是 EXT 文件系统中的元数据的关键组件。 图 2 显示了 inode 和存储在硬盘驱动器上的数据之间的关系。 该图是单个文件的目录和 inode，在这种情况下，可能会产生高度碎片化。 EXT 文件系统可以主动地减少碎片，所以不太可能会看到有这么多间接数据块或扩展盘区的文件。 实际上，你在下面将会看到，EXT 文件系统中的碎片非常低，所以大多数 inode 只使用一个或两个直接数据指针，而不使用间接指针。图 2 ：inode 存储有关每个文件的信息，并使 EXT 文件系统能够查找属于它的所有数据。inode 不包含文件的名称。通过目录项访问文件，目录项本身就是文件的名称，并包含指向 inode 的指针。该指针的值是 inode 号。文件系统中的每个 inode 都具有唯一的 ID 号，但同一台计算机上的其它文件系统（甚至是相同的硬盘驱动器）中的 inode 可以具有相同的 inode 号。这对 硬链接 存在影响，但是这个讨论超出了本文的范围。inode 包含有关该文件的元数据，包括其类型和权限以及其大小。 inode 还包含 15 个指针的空位，用于描述柱面组数据部分中数据块或扩展盘区的位置和长度。12 个指针提供对数据扩展盘区的直接访问，应该足以满足大多数文件的需求。然而，对于具有明显分段的文件，需要以间接 节点 （ node ） 的形式提供一些额外的容量——从技术上讲，这些不是真正的“inode”，所以为了方便起见我在这里使用这个术语“ 节点 （ node ） ”。间接节点是文件系统中的正常数据块，它仅用于描述数据而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节的间接节点，允许单个文件有 12（直接）+ 512（间接）= 524 个扩展盘区。还支持双重和三重间接节点，但我们大多数人不太可能遇到需要那么多扩展盘区的文件。数据碎片对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理本身就成为一个行业，有各种品牌的整理软件，其效果范围从非常有效到仅仅是微乎其微。Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 fsck 命令检查整个文件系统的碎片。 以下示例检查我的主工作站的家目录，只有 1.5％ 的碎片。 确保使用 -n 参数，因为它会防止 fsck 对扫描的文件系统采取任何操作。fsck -fn /dev/mapper/vg_01-home 我曾经进行过一些理论计算，以确定磁盘碎片整理是否会产生任何明显的性能提升。 我做了一些假设条件，我使用的磁盘性能数据来自一个新的 300GB 的西部数字硬盘驱动器，具有 2.0ms 的轨到轨寻道时间。 此示例中的文件数是我在计算的当天的文件系统中存在的实际数。 我假设每天有相当大量的碎片化文件（约 20％）会被用到。全部文件271,794碎片率 %5.00%不连续数13,590 % 每天用到的碎片化文件20% （假设）额外寻道次数2,718平均寻道时间10.90 ms每天全部的额外寻道时间29.63 sec 0.49 min 轨到轨寻道时间2.00 ms每天全部的额外寻道时间5.44 sec 0.091 min表 1: 碎片对磁盘性能的理论影响我对每天的全部的额外寻道时间进行了两次计算，一次是轨到轨寻道时间，这是由于 EXT 文件分配策略而导致大多数文件最可能的情况，一个是平均寻道时间，我假设这是一个合理的最坏情况。从表 1 可以看出，对绝大多数应用程序而言，碎片化甚至对性能适中的硬盘驱动器上的现代 EXT 文件系统的影响是微乎其微的。您可以将您的环境中的数字插入到您自己的类似电子表格中，以了解你对性能影响的期望。这种类型的计算不一定能够代表实际的性能，但它可以提供一些对碎片化及其对系统的理论影响的洞察。我的大部分分区的碎片率都在 1.5％ 左右或 1.6％，我有一个分区有 3.3％ 的碎片，但是这是一个大约 128GB 文件系统，具有不到 100 个非常大的 ISO 映像文件；多年来，我扩展过该分区几次，因为它已经太满了。这并不是说一些应用的环境并不需要更少的碎片的环境。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以针对特定的工作负载类型调整参数。这个工作可以在文件系统创建的时候或稍后使用 tune2fs 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上混用文件系统类型以匹配每个文件系统上的不同负载是常见的。由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。目前，EXT 文件系统没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片程度或文件系统中剩余可用空间的碎片程度。有一个工具，e4defrag，它可以对允许使用的剩余可用空间、目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件移动从而进行碎片整理，并在确保安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全去碎片化。总结EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和性能。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时我发现了它们适用于任何主流负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显需要使用其它文件系统的理由。作者简介：David Both - David Both 是一名 Linux 于开源的贡献者，目前居住在北卡罗莱纳州的罗利。他从事 IT 行业有 40 余年并在 IBM 中从事 OS/2 培训约 20 余年。在 IBM 就职期间，他在 1981 年为最早的 IBM PC 写了一个培训课程。他已经为红帽教授了 RHCE 课程，曾在 MCI Worldcom，思科和北卡罗来纳州工作。 他使用 Linux 和开源软件工作了近 20 年。via: https://opensource.com/article/17/5/introduction-ext4-filesystem作者：David Both 译者：chenxinlong 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
老实说，人们最不曾思考的问题之一是他们的个人电脑中使用了什么文件系统。Windows 和 Mac OS X 用户更没有理由去考虑，因为对于他们的操作系统，只有一种选择，那就是 NTFS 和 HFS+。相反，对于 Linux 系统而言，有很多种文件系统可以选择，现在默认的是广泛采用的 ext4。然而，现在也有改用一种称为 btrfs 文件系统的趋势。那是什么使得 btrfs 更优秀，其它的文件系统又是什么，什么时候我们又能看到 Linux 发行版作出改变呢？首先让我们对文件系统以及它们真正干什么有个总体的认识，然后我们再对一些有名的文件系统做详细的比较。文件系统是干什么的？如果你不清楚文件系统是干什么的，一句话总结起来也非常简单。文件系统主要用于控制所有程序在不使用数据时如何存储数据、如何访问数据以及有什么其它信息（元数据）和数据本身相关，等等。听起来要编程实现并不是轻而易举的事情，实际上也确实如此。文件系统一直在改进，包括了更多的功能、更高效地完成它需要做的事情。总而言之，它是所有计算机的基本需求、但并不像听起来那么简单。为什么要分区？由于每个操作系统都能创建或者删除分区，很多人对分区都有模糊的认识。Linux 操作系统即便使用标准安装过程，在同一块磁盘上仍使用多个分区，这看起来很奇怪，因此需要一些解释。拥有不同分区的一个主要目的就是为了在灾难发生时能获得更好的数据安全性。通过将硬盘划分为分区，数据会被分隔以及重组。当事故发生的时候，只有存储在被损坏分区上的数据会被破坏，很大可能上其它分区的数据能得以保留。这个原因可以追溯到 Linux 操作系统还没有日志文件系统、任何电力故障都有可能导致灾难发生的时候。使用分区也考虑到了安全和健壮性原因，因此操作系统部分损坏并不意味着整个计算机就有风险或者会受到破坏。这也是当前采用分区的一个最重要因素。举个例子，用户创建了一些会填满磁盘的脚本、程序或者 web 应用，如果该磁盘只有一个大的分区，如果磁盘满了那么整个系统就不能工作。如果用户把数据保存在不同的分区，那么就只有那个分区会受到影响，而系统分区或者其它数据分区仍能正常运行。记住，拥有一个日志文件系统只能在掉电或者和存储设备意外断开连接时提供数据安全性，并不能在文件系统出现坏块或者发生逻辑错误时保护数据。对于这种情况，用户可以采用 廉价磁盘冗余阵列 （ RAID：Redundant Array of Inexpensive Disks ） 的方案。为什么要切换文件系统？ext4 文件系统由 ext3 文件系统改进而来，而后者又是从 ext2 文件系统改进而来。虽然 ext4 文件系统已经非常稳定，是过去几年中绝大部分发行版的默认选择，但它是基于陈旧的代码开发而来。另外， Linux 操作系统用户也需要很多 ext4 文件系统本身不提供的新功能。虽然通过某些软件能满足这种需求，但性能会受到影响，在文件系统层次做到这些能获得更好的性能。Ext4 文件系统ext4 还有一些明显的限制。最大文件大小是 16 tebibytes（大概是 17.6 terabytes），这比普通用户当前能买到的硬盘还要大的多。使用 ext4 能创建的最大卷/分区是 1 exbibyte（大概是 1,152,921.5 terabytes）。通过使用多种技巧， ext4 比 ext3 有很大的速度提升。类似一些最先进的文件系统，它是一个日志文件系统，意味着它会对文件在磁盘中的位置以及任何其它对磁盘的更改做记录。纵观它的所有功能，它还不支持透明压缩、重复数据删除或者透明加密。技术上支持了快照，但该功能还处于实验性阶段。Btrfs 文件系统btrfs 有很多不同的叫法，例如 Better FS、Butter FS 或者 B-Tree FS。它是一个几乎完全从头开发的文件系统。btrfs 出现的原因是它的开发者起初希望扩展文件系统的功能使得它包括快照、 池化 （ pooling ） 、校验以及其它一些功能。虽然和 ext4 无关，它也希望能保留 ext4 中能使消费者和企业受益的功能，并整合额外的能使每个人，尤其是企业受益的功能。对于使用大型软件以及大规模数据库的企业，让多种不同的硬盘看起来一致的文件系统能使他们受益并且使数据整合变得更加简单。删除重复数据能降低数据实际使用的空间，当需要镜像一个单一而巨大的文件系统时使用 btrfs 也能使数据镜像变得简单。用户当然可以继续选择创建多个分区从而无需镜像任何东西。考虑到这种情况，btrfs 能横跨多种硬盘，和 ext4 相比，它能支持 16 倍以上的磁盘空间。btrfs 文件系统一个分区最大是 16 exbibytes，最大的文件大小也是 16 exbibytes。XFS 文件系统XFS 文件系统是 扩展文件系统 （ extent file system ） 的一个扩展。XFS 是 64 位高性能日志文件系统。对 XFS 的支持大概在 2002 年合并到了 Linux 内核，到了 2009 年，红帽企业版 Linux 5.4 也支持了 XFS 文件系统。对于 64 位文件系统，XFS 支持最大文件系统大小为 8 exbibytes。XFS 文件系统有一些缺陷，例如它不能压缩，删除大量文件时性能低下。目前RHEL 7.0 文件系统默认使用 XFS。总结不幸的是，还不知道 btrfs 什么时候能到来。官方说，其下一代文件系统仍然被归类为“不稳定”，但是如果用户下载最新版本的 Ubuntu，就可以选择安装到 btrfs 分区上。什么时候 btrfs 会被归类到 “稳定” 仍然是个谜， 直到真的认为它“稳定”之前，用户也不应该期望 Ubuntu 会默认采用 btrfs。有报道说 Fedora 18 会用 btrfs 作为它的默认文件系统，因为到了发布它的时候，应该有了 btrfs 文件系统校验器。由于还没有实现所有的功能，另外和 ext4 相比性能上也比较缓慢，btrfs 还有很多的工作要做。那么，究竟使用哪个更好呢？尽管性能几乎相同，但 ext4 还是赢家。为什么呢？答案在于易用性以及广泛性。对于桌面或者工作站， ext4 仍然是一个很好的文件系统。由于它是默认提供的文件系统，用户可以在上面安装操作系统。同时， ext4 支持最大 1 exabytes 的卷和 16 terabytes 的文件，因此考虑到大小，它也还有很大的进步空间。btrfs 能提供更大的高达 16 exabytes 的卷以及更好的容错，但是，到现在为止，它感觉更像是一个附加的文件系统，而部署一个集成到 Linux 操作系统的文件系统。比如，尽管 btrfs 支持不同的发行版，使用 btrfs 格式化硬盘之前先要有 btrfs-tools 工具，这意味着安装 Linux 操作系统的时候它并不是一个可选项，即便不同发行版之间会有所不同。尽管传输速率非常重要，评价一个文件系统除了文件传输速度之外还有很多因素。btrfs 有很多好用的功能，例如 写复制 （ Copy-on-Write ） 、扩展校验、快照、清洗、自修复数据、冗余删除以及其它保证数据完整性的功能。和 ZFS 相比 btrfs 缺少 RAID-Z 功能，因此对于 btrfs， RAID 还处于实验性阶段。对于单纯的数据存储，和 ext4 相比 btrfs 似乎更加优秀，但时间会验证一切。迄今为止，对于桌面系统而言，ext4 似乎是一个更好的选择，因为它是默认的文件系统，传输文件时也比 btrfs 更快。btrfs 当然值得尝试、但要在桌面 Linux 上完全取代 ext4 可能还需要一些时间。数据场和大存储池会揭示关于 ext4、XCF 以及 btrfs 不同的场景和差异。如果你有不同或者其它的观点，在下面的评论框中告诉我们吧。via: http://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/作者：M.el Khamlichi 译者：ictlyh 校对：Caroline本文由 LCTT 原创编译，Linux中国 荣誉推出