云盘文件系统比较：Ext4、XFS和Btrfs
原创
0x00 背景
在上一篇云硬盘性能分析的教程中，为大家介绍了如何评测云硬盘的读写性能。但是，我们使用硬盘，从来不是直接读写裸设备，而是通过文件系统来管理和访问硬盘上地文件。不少朋友询问，文件系统该如何对比，又该如何选择呢？
文件系统的选择，其重要性不言而喻，可能仅次于Linux发行版的选择。其实，各个文件系统在功能及性能方面是有不小的差异的。本文中，我们将一起探索Linux中主流的三个文件系统——Ext4、XFS以及Btrfs——的功能特点，并基于腾讯云高性能云硬盘，做一个初步的性能对比。
0x01 文件系统
首先，我们简单感受下什么是文件系统。文件系统（File System或fs），定义并实现了数据在存储介质（如硬盘等）上的存储方式和结构，以及其是如何被访问的，如索引、读取等。操作系统里，硬盘中的数据被抽象为文件的形式，并对其进行管理，比如为一块或多块数据关联一个文件名等，因此，我们称这些用于管理文件的数据结构（以及其对应的规则）为文件系统，就再自然不过了。Unix中更是讲一切皆文件，可见文件系统的地位非常之高。
当然，随着技术的发展，现代的文件系统特性也越来越多，如Btrfs等文件系统，支持快照、子卷、校验和自检、软RAID甚至透明压缩等，这些虽不是传统文件系统所做的事，但却是一种不可阻挡的趋势。
文件系统通常作为操作系统的一部分，如Linux中是作为子系统而实现在内核里的。我们接下来要介绍的Ext4、XFS、Btrfs都是实现在Kernel代码中的fs目录下。文件系统需要实现操作系统所定义的对象和接口，如inode、dentry等。
如上图所示，super block对象用于描述挂载文件系统的元信息，即文件系统控制块；inode对象就是存储一个文件的通用信息，如时间戳、所对应的数据块位置等；dentry对象存储一个文件的目录项的链接信息，也就是文件的路径名，因为一个文件可能有多个链接。以上三者都是由文件系统各自实现并以特定格式持久化存储在硬盘上的。那么，什么时候存上的呢？对于一些文件系统如Ext4等，在硬盘格式化时就全部确定了，而对于XFS则是动态生成的，BtrfS则是更特别的动态实现。但无论如何，各个文件系统都需要存储这三类信息，因为这是内核规定的（见下）。另外，我们常说的file对象，它用于关联进程和dentry对象的，可以简单理解成正在打开的文件，它是存在内存里的，千万不要搞混，file对象并不存在file system里。
Linux中的VFS（Virtural File System 或 Virtual FS Switch）作为具体的文件系统的抽象层，是非常重要的。它为各类文件系统提供了一个一致的接口，如必须支持哪些POSIX兼容的系统调用等，用户态的应用无需关注底层具体文件系统的区别，通过相同的系统调用请求内核即可。还是得益于VFS，我们甚至可以通过FUSE等机制来实现用户态的文件系统，比如GlusterFS、IPFS等。
0x02 各文件系统简介
本章简单介绍Linux三类文件系统：Ext4、XFS、Btrfs。
Ext4
Ext4（ext4日志文件系统、第四代扩展文件系统）文件系统是Linux用途最广泛的日志文件系统。Ext4稳定版本发布于2008年，即Linux 2.6.28版本。但它的历史最早可以追溯到1992年的Ext2文件系统，那是Linux最早使用的文件系统，而后2001年出现的Ext3在Ext2基础上增加了日志功能，并最终由Ext4替代，而且Ext4可向前兼容Ext2/Ext3。Ext4是很多发行版如Debian、Ubuntu等的默认文件系统。
什么是日志（Journaling）文件系统？就是在数据更改正式提交至硬盘之前，先在日志区域（也是存在文件系统上的）记录变更日志，这样可以在系统崩溃或掉电后能快速恢复。现代的文件系统，甚至各类可靠的存储系统，日志存储都是必须的。
Ext4在Ext3的基础上，又增加了不少新特性。第一，大文件支持，最大卷1EiB，最大文件16TiB（对于4KiB块）。Ext4中实现了基于extent的数据管理。extents可以简单理解为连续的块，有了它管理大文件就更方便，大大降低了用于索引大文件的元数据量——原来用间接块索引（Indirect Block）的方法是非常浪费的——自然访问也性能也提升。而且，Ext4的inode比Ext3大一倍，达到256字节。不过话说回来，2008年那时所谓的“大”文件，到今天看来也就一般，如今谁还没有个几百兆甚至上GiB的视频呢。第二，增加并优化了日志校验和（journal check summing）功能，就是fsck过程更快了。这两个特性也是必须要有的，其实XFS和Btrfs也都支持。另外还有些特性如无日志模式、多块分配、延迟分配、在线去除碎片（defragmentation）等。
上图是Ext系列文件系统的数据存储schema，硬盘分区被等分成N个同样大小的块组，方便索引。每个快组又分为super block、group descriptors、data block bitmap、inode table，以及最后数据块区域。bitmap块表示对应的块/inode是否被分配。全部文件系统的元信息可以通过dumpe2fs工具查看，注意需要umount后才是最新的。
可以看出，数据块总量受制于Bitmap块的大小，所以每个块组最多也就4096*8=32768个数据块。另外inode数一般是数据块的四分之一，其数量也是在格式化时固定的，理论上inode耗尽时，即便还有空间，也是无法再创建新文件的。查看inode占用量可以通过df -ih来查看。
为什么是4KiB的块大小（Block Size），这个数字怎么总出现？块是文件系统操作设备的最小单元。硬盘寻址的最小单位是512B，文件系统操作的块大小需要是它的整数倍且是2的幂次，而且不能超过内存页帧大小（通常是4096B），可选的就是512、1024、2048和4096，为了提升吞吐率，所以基本就都是4KiB的块。
XFS
XFS是1993年由SiliconGraphic Inc(SGI) 公司创建的高性能的64位文件系统。2001年进入Linux内核，如今已被大多数Linux发行版支持。最支持的要数红帽公司，其下主打的操作系统RHEL（Red Hat Enterprise Linux）7和8——即最近两个稳定版——都选XFS为默认的文件系统，红帽的很多工程师也深度参与了XFS的开发和维护。
XFS的文件系统结构如上，不同于Ext4，它通过B+树来索引inode和数据块。用树结构的文件系统通常相比Ext4用表结构，如链表、直接/间接Block以及extent，能更好地支持大文件，如视频/数据库文件等。另外其元数据规模少，使得硬盘可用空间更多，实测XFS、Btrfs多平均至少1.5%以上的可用空间。
XFS能支持多大文件呢？单卷可达8EiB，最大文件也到8EiB，相比Ext4的16TiB可高了几个数量级。而且是其实动态分配inode的实现机制，只要有空间，就不会耗尽inode。通过df命令看出，其inode初始值就是ext4的10倍左右。
另外，XFS可以更高效支持并行IO操作，RAID上的扩展性更好，多线程并行读写时相比Ext4有优势。
Btrfs
Btrfs，是B-Tree File System的缩写，可以读作“butter fs”或“b-tree fs”，是一个支持copy-on-write (COW)的文件系统，由Oracle公司于2007年设计并使用，2013年进入Linux内核稳定发布。 目前除了Oracle外，SUSE Linux Enterprise Server将其用作默认文件系统，而在工作站领域中，Fedora 33也将其作为默认文件系统，Facebook公司也大量应用了Btrfs文件系统。
Btrfs的强大之处，在于实现了很多先进特性的同时，还保持了很高的容错能力、可扩展性以及可靠性。其最早的COW B-tree的数据结构也是2007年才提出的，Btrfs比Ext4、XFS小了近20年，的确是个现代文件系统，那么它不一样在哪里，有哪些面向未来的特性呢？
那么，什么是COW的文件系统？你或许听说过创建子进程时的内存分页中的COW机制：进程创建时并不申请真正内存，而是在写内存是通过触发page fault动态申请，on-demand分配提升了资源利用率和系统响应性能。COW的文件系统也是用了类似的机制，这种机制比日志，能更高效地保证了数据的一致性（consistency）和完整性（Integrity），同时提升了系统自修复、快照功能的性能。
特性上，Btrfs支持得更多：大文件支持是必须的，16EiB最大卷和文件大小；集成了卷管理功能，可以以卷的方式动态地增减设备，实现硬盘资源池化；高效的数据完整性check，如基于cow的自恢复（self-healing）、基于checksum的数据清理（data scrubbing）；高性能的读写/只读快照，得益于cow，增量快照和备份非常直接、灵活且低成本；软raid支持，数据和元数据的stripe和mirror生产环境级别支持；透明的压缩，支持lzo和zlib；在线去碎片（online defragmentation）；数据去重（data deduplication）。
这方面，与其说是更好的文件系统，倒不如说它把传统的逻辑卷管理（如LVM）、软RAID（如mdadm）等工具做的工作集成在了文件系统层面上，方便了系统管理员，确实是一大进步。
0x03 文件系统的使用
格式化
对于分区格式化，通过mkfs命令即可，不过对于某些发行版，需要安装对应的文件系统utility工具。而这3个文件系统，现在的主流内核早已全部稳定支持。
# 格式化成 Ext4
mkfs.ext4 /dev/vdb1
# 格式化为 XFS
apt install xfsprogs
mkfs.xfs /dev/vdb2
# 格式化为 Btrfs
apt install btrfs-progs
mkfs.btrfs /dev/vdb3用量查看
对于Ext4和XFS用df命令即可查看数据和inode的用量
df -h # 查看硬盘用量
df -ih # 查看硬盘inode用量Btrfs则相对特殊一些，因为它是COW的文件系统，最好不要用df查看容量，因为不准；我们也无法用df -i查看inode数量的，会显示0，因为Btrfs根本没有inode预设限制。通过btrfs命令来查看用量。
btrfs filesystem usage /your/btrfs/directory命令执行如下图：
当然，Btrfs可玩的东西比较多，如子卷、快照、raid、数据恢复等，这些特性后续值得专门再单独分析介绍。
不过在云硬盘场景下，以上各中工作其实都已经完全托管实现了，腾讯云的CBS云硬盘产品，通过多副本的机制保障了数据的可靠性、可用性等问题，同时并发性能也得到特别的优化。
0x04 云盘上各文件系统性能对比
实验环境选择x86_64体系下的Debian 10 (Buster)稳定版的OS，每种文件系统均为1T的高性能云硬盘。
格式化
Ext4: 7.137s, XFS: 5.871s, Btrfs: 1.428s （第二次即以后仅要0.046s） Btrfs > XFS > Ext4
顺序读
fio -name=read-throughput -readwrite=read -blocksize=128k -numjobs=2 -ioengine=libaio -iodepth=1 -direct=1 -runtime=60 -refill_buffers -norandommap -randrepeat=0 -group_reporting --size=10G -filename=/data/ext4/aExt4: IOPS=3039, BW=380MiB/s
XFS: IOPS=3145, BW=393MiB/s
Btrfs: IOPS=3132, BW=392MiB/s
读吞吐量：XFS、Btrfs差不多，相比Ext4稍有优势。
顺序写
fio -name=write-throughput -readwrite=write -blocksize=128k -numjobs=2 -ioengine=libaio -iodepth=1 -direct=1 -runtime=60 -refill_buffers
-norandommap -randrepeat=0 -group_reporting --size=10G -filename=/data/xfs/aExt4: IOPS=1056, BW=132MiB/s
XFS: IOPS=1023, BW=128MiB/s
Btrfs: IOPS=1007, BW=126MiB/s
写吞吐量：线程少的时候，总体差不多，Ext4略快一些。
4K随机读
fio -name=read-latency-iops -readwrite=randread -blocksize=4k -numjobs=2 -ioengine=libaio -iodepth=1 -direct=1 -runtime=60 -refill_buffers -norandommap -randrepeat=0 -group_reporting --size=10G -filename=/data/btrfs/aExt4: IOPS=7254, BW=28.3MiB/s
XFS: IOPS=8202, BW=32.0MiB/s
Btrfs: IOPS=7923, BW=30.0MiB/s
4K随机读，XFS > Btrfs > Ext4。
性能测试总结，在腾讯云的CBS云硬盘上，对于以上三种成熟稳定的文件系统，不论选用其中哪一种，性能都比较优异，且差异相对不大。
0x05 小结
至此，我们一起熟悉了文件系统的概念、以及常见主流的三大文件系统（Ext4、XFS、Btrfs）的各自特点及使用方法、场景以及各自的比较，并实测了其在云服务器中的性能。那么综合以上的分析，你的业务产经更适合倾向于哪种文件系统呢？
欢迎订阅专栏：巫山跬步，关注本文作者：溪歪歪，持续获取云服务技术的最佳实践讲解。感谢点赞支持！
0x06 参考资料
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。