为什么这么设计(Why’s THE Design)是一系列关于计算机领域中程序设计决策的文章,我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题,可以在文章下面留言。
相信今天很多的软件工程师使用的都是 Linux 或者 macOS 系统,与 Windows 不同,我们很难看到磁盘碎片整理这一概念,从个人的经验来看,作者在过去七八年没有在 macOS 中整理过磁盘的碎片,你在今天的磁盘工具中也找不到相关的操作,只能通过 diskutil 命令设置某一块磁盘是否开启或者关闭碎片整理。
图 1 - macOS 磁盘工具 我们在 [前一篇文章] 中曾经分析过为什么早期 Windows 操作系统每隔一段时间可能需要整理磁盘上的碎片[^1],该问题背后有两个原因,其一是 Windows 使用的 FAT 是很简单的文件系统,该文件系统的设计决定了同一份文件可能会散落在磁盘的不同位置,其二是固态硬盘在上古时代没有普及,机械硬盘的随机读写性能很差。
Linux 和 macOS 系统不需要碎片整理的原因与 Windows 需要碎片整理的原因正好相反:
Linux 一般都使用 Ext2、Ext3 和 Ext4 文件系统,今天的大多数 Linux 发行版都选择了 Ext4。与 Windows 将多个文件连续存储的方式不同,Linux 会把文件散落到磁盘的不同地方存储,同时在文件之间留下一些空间,保证文件在修改或者更新时不会造成碎片。
图 2 - Linux 文件系统[^2] 今天的 macOS 多数都使用 APFS 文件系统[^3],它是苹果专门为固态硬盘等设备优化的文件系统。更早的 HFS 和 HFS+ 都是用了基于区块(Extent)的设计,每个区块都包含序号和一段连续的存储空间,这种分配方式会在文件系统中查找几个连续的区块来提供所需的空间。
图 3 - macOS 文件系统 无论是 Linux 还是 macOS,它们的文件系统都是基于区块设计的,而磁盘的空间分配也相对比较合理,所以不会出现 Windows 系统上碎片化的磁盘。
除了文件系统在设计就避免了碎片的出现之外,Linux 和 macOS 也都是引入了延迟分配空间的策略,它们会通过缓冲区尽可能延迟磁盘写入的时间,这样不仅能够降低刷盘的概率,还能增加文件写入相邻区块的概率,然而这种机制并不是没有副作用,在系统断电或者崩溃时可能会丢失更多的数据。
如果磁盘上确实出现了碎片,那么 Linux 和 macOS 的文件系统也会尝试移动出现碎片的文件,不需要额外的碎片整理工具,这种设计带来的用户体验会比手动触发耗时较长的碎片整理好很多。macOS 上的 HFS+ 系统还支持实时的去碎片化,当满足以下条件时会触发碎片整理[^4]:
在多数情况下,这些操作系统中的磁盘碎片比例都非常低,只有在磁盘空间不足时才会开始出现碎片,所以在这时我们其实需要的是一个更大的磁盘或者更新的电脑,而不是整理磁盘上的碎片。
固态硬盘其实已经是有着三十年历史的存储介质了,但是由于固态硬盘的价格在过去一直都十分昂贵,所以没有在数据中心和个人电脑中普及开来。哪怕是在今天,机械磁盘的价格与固态硬盘相比也有比较明显的优势。
图 4 - 固态硬盘和机械硬盘价格对比 新型的存储介质带来了全新的特性和性能,我们在前一篇文章中曾经介绍过,因为机械硬盘的机械结构,所以它的随机 I/O 与顺序的 I/O 性能可能相差几百倍,碎片整理可以将散落在磁盘上的数据合并到一处,随机 I/O 的次数减少自然也会提高读写文件的性能。
固态硬盘的顺序 I/O 和随机 I/O 在性能上虽然也有差异,但是差距可能在十几倍到几十倍之间,而固态硬盘的随机 I/O 延迟也比机械磁盘好几十倍甚至上千倍,到现在来看整理固态硬盘上的碎片虽然有收益,但是也比较有限。
图 5 - NAND 闪存的演进 作为电子元件的固态硬盘虽然有着较好的性能表现,但是固态硬盘都有循环擦写的次数限制,也被称作 P/E。它的寿命与机械硬盘相比却比较有限。如果一个 512 GB 的固态硬盘的擦写数目是 1000 次,每次写满数据都会消耗一次寿命,等擦写次数达到 1000 次之后硬盘就会报废,碎片整理其实就是主动移动硬盘上的数据,自然会影响硬件的寿命。
在软件工程中有一个非常有趣的现象,做硬件和基础架构的工程师都在拼命优化系统的性能,然而应用层的工程师很多时候并不在乎性能上的微小差异,而这也是工作职责上的差异带来的结果,不同的位置决定了不同的关注点。
硬件的演进和革新深深地影响着上层软件的设计,想要设计出通用的系统是异常困难的,在设计文件系统时如果不考虑底层硬件的特性,也就无法充分利用硬件提供的性能并得到期望的结果。这里简单总结一下 Linux 和 macOS 不需要碎片整理的两个原因:
到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题,与前面的问题不同,作者会在后面的文章中解答这两个问题:
如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因,可以在博客下面留言,作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。
[^1]: 为什么早期的 Windows 需要整理碎片 https://draveness.me/whys-the-design-windows-defragmentation/
[^2]: Is there a tool to visualize a filesystem allocation map on Linux? https://unix.stackexchange.com/questions/30743/is-there-a-tool-to-visualize-a-filesystem-allocation-map-on-linux
[^3]: Wikipedia: Apple File System https://en.wikipedia.org/wiki/Apple_File_System
[^4]: HFS+ and File System Fragmentation https://developercoach.com/file-system-fragmentation/
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8