Linux文件系统的未来
Last updated
Was this helpful?
Last updated
Was this helpful?
我整理和汇总这篇文档的原因是最近一次在Btrfs上运行KVM虚拟机的时候，会出现Btrfs报错csum failed，随后出现CPU超过限值：
此时 top 观察系统处理器use和sys都不高，还有较多idle，但是系统负载达到10+，超过了主机cpu个数，运行非常缓慢。强制杀掉VM后回复正常。
另外一个现象是在 /var/lib/libvirt/images 目录下压缩30G大小Windows镜像，压缩非常缓慢远超过1小时，并且压缩文件解压缩以后，Wiondows虚拟机运行时显示磁盘文件系统损坏，而且Windows自动修复重启guest，但显示无法找到启动磁盘。这意味着虚拟机镜像破坏。
对比配置，可以看到我在这次arch linux的实践配置btrfs和之前在Ubuntu 18.04上配置的差异是，arch linux上的btrfs启用了磁盘压缩功能，启用了zstd。这个压缩功能可能引入了不稳定的因素。
最近(2019年9月底)，CentOS 8终于release，我惊讶发现，CentOS 8移除了btrfs文件系统支持。实际上，是上游 ，已经不能在RHEL 8/CentOS 8中创建和挂载Btrfs文件系统，，但这带来极大的维护成本（每次内核升级都需要自己维护版本）。
早在2017年phoronix新闻已经公布了Red Hat放弃btrfs，并且在介绍了Red Hat的（一种本地文件系统），结合XFS和device-mapper来实现类似ZFS的技术。当前的实现是采用用户空间daemon来管理：
当前支持Btrfs的主流发行版本是SUSE，企业级应用案例是FaceBook。相信FaceBook这样的体量能够在内部针对btrfs进行深度定制和bug修复，以便能够充分发挥其特定优势。实际上大厂都有这样的开发团队来维护开源软件的特定分支，针对其业务特殊性定制。
btrfs长期处于技术预览阶段，功能稳定性一直没有达到生产级别；与此同时，其他文件系统的进步和发展已经逐步具备了btrfs的功能，并且正确组合现有稳定的存储技术，如ext4, XFS, LVM等，就可以实现btrfs承诺的特性
不能稳定支持RAID5/6（官方wiki也这样说明）：
对于大型公司(例如FaceBook)可能可以通过底层RAID硬件来弥补这个缺陷。
但是，随着现代化大型服务器使用的海量存储磁盘，如果发生磁盘故障，不论是软件RAID还是硬件RAID，底层RAID的同步复制会导致其他磁盘巨大的压力，由于同步时间周期极长，在同步期间，极有可能发生连锁的磁盘故障而导致数据丢失。
所以，在现代数据中心海量存储中，不建议使用RAID 5，而建议采用类似Ceph这样的分布式文件系统，将数据块部分分散到集群海量数量磁盘上，降低单磁盘故障风险。如果不得已要使用RAID，也至少要使用RAID6，推荐RAID10，并配置足够多的spare盘以便故障自动替换。
实际上，在Linux平台的文件系统中，ZFS由于较为完善地内建了RAID功能，所以比Btrfs有很大的优势。ZFS不需要底层RAID系统，直接控制单盘并实现RAID，可以较好地在文件系统层感知底层的硬件故障。所以，Red Hat的客户可能大多使用ZFS而不使用Btrfs，这样Red Hat抛弃Btrfs才能实行。
对于大型数据中心，Ceph分布式存储系统将数据块分散到海量服务器磁盘中，避免了硬件故障以及强制的整块故障硬盘数据复制(对数据修复的源、目的磁盘压力极大)。这也是当前大型集群的优选存储方案。并且Ceph已经发展成不需要底层文件系统，也是Red Hat主推的数据存储解决方案(Red Hat已经收购了Ceph)
如果文件系统发起TRIM请求(discard丢弃)，这个请求除了会转发给硬盘外，MD（即RAID）会记录一个或多个条代(strip)不再存储有用的信息（这个标志位会因为对条代的写入而失效）。在恢复过程中，进入每个条代的状态，MD只能处理RAID阵列的有效部分。
对于大型TRIM请求，TRIM请求是块细粒度的。为了正确跟踪哪些条代有有效数据，MD需要为每个数据块记录这个数据块是否有有效数据。否则，就不能确定某些TRIM请求是否已经从条代中删除了最后使用的块。
以上对话似乎是表示MD对TRIM跟踪不利
Red Hat放弃支持Btrfs可能是为了迫使下游发行Oracle Linux的Oracle公司加强合作并投入资源推动Btrfs稳定进入RHEL。因为没有Red Hat上游支持，Oracle要投入更多资源才能在clone lnux中稳定运行Btrfs
Red Hat雇佣了大量的XFS开发人员，其内部主要的本地文件系统开发团队都围绕XFS进行，所以XFS是Red Hat主要支持技术
Red Hat擅长雇佣不知名的开源开发者并帮助其获得开源影响力；但Red Hat待遇比Facebook,Google等大厂要低。如果能在Red Hat公司中成长起来，往往能够得业界较好的职位。
XFS在数据库类型的高端应用上有较大性能优势（比EXT4性能要好），ZFS需要相应调整数据库参数，例如ZFS已经提供了保障就不需要开启InnoDB的双写缓存，此外还要条增数据库内存页大小，否则ZFS不能发挥良好的性能。
需要结合LVM来使用ext4/xfs，否则不能获得类似ZFS的快照功能。
btrfs在创建或删除快照的时候影响存储性能：Btrfs不区分clone和snapshot，两者相同，并带有标志位。
这种设计表面看起来简单方便，但是副作用是效率很低。
ZFS的快照归数据集所有，几乎没有刷新计数的开销，只是根据简单的交易ID编号将区块移动到deadlist。如果你修改了一个块，并且其事务ID大于最新快照，就以对其进行处理;否则就将其添加到快照deadlist(并添加新的更新块)。如果删除快照，则执行相同操作：对于每个块，如果块事务ID早于上一个快照的事务ID，则其丢弃，否则将其移至上一个快照的deadlist。除了减量处置外，没有其他变更。只有在创建clone时候ZFS才有开销，所以ZFS快照非常轻松。
但是Btrfs的快照则代价高昂。
ZFS具有细粒度的权限委派体系，这个体系通过数据集关系而不是功能继承。
XFS缺乏透明压缩功能，这个功能可能在MD层面可以实现？
本地文件系统通常采用服务器内建的SATA和SAS磁盘，也包含通过SAN连接的存储(因为SAN输出的设备是不共享的)
早期RHEL 4/5主要使用Ext2和Ext3文件系统，从RHEL 5.6开始全面支持Ext4
XFS是64位日志型文件系统，支持单机运行及非常巨大的文件，从RHEL 7开始成为默认文件系统
XFS是1990年代由SGI开发，经过漫长的发展已经成为成熟稳定的文件系统并提供了丰富的特性:
延迟分配
动态分配inode
B叉树索引支持空闲空间管理的伸缩性
支持大量并发操作
充分的运行时元数据一致性检查
精巧的元数据预读算法
稳定集成的备份和回复工具
在线碎片整理
在线文件系统扩展
全面的诊断能力
可伸缩和快速的修复工具
针对流视频工作负载的优化
Ext4是RHEL 6的默认文件系统，支持特性:
扩展元数据
延迟分配
日志教研
支持大型存储
选择文件系统的建议:
根据操作系统版本的推荐默认文件系统选择
Ext3/Ext4文件系统在有限的带宽(<200MB/s)和最多1000IOPS环境下性能较好；对于更高压力和性能要求，则适合使用XFS。
XFS比Ext3/Ext4每个元数据操作消耗2倍的CPU，所以需要更多处理器资源：如果CPU负载能力有限，则Ext3/Ext4性能更好。总之，如果应用使用一个单一的读/写线程并且是小文件则Ext3或Ext4更合适；而XFS适合多线程读写和较大文件的应用程序。
RHEL 6开始较好支持了SSD trim，并且自动检测和对齐文件系统。
共享型网络文件系统
RHEL 6之前提供了GFS1，RHEL 6开始采用GFS2，最高支持16个节点。
，有用户和Red Hat工程师讨论，主要的观点有：
基于上述理由，Red Hat推出了结合XFS和LVM的存储管理解决方案，目前已经释出1.0版本，实现了阶段性目标。在RHEL 8中，已经包含了Stratis存储解决方案，并且被标记为"Technology Preview"。
从 2017 年LWN讨论 提到了btrfs的一些缺陷:
anton用户提供信息信息介绍Btrfs组建RAID1遇到bug导致一块磁盘fail并进入只读文件系统模式，通过复制进行恢复，但没有丢失数据。
在Haker News上有关讨论：
XFS最新支持了CoW功能 - 见 ，即 RHEL 8默认激活XFS的CoW功能，这个功能的工具支持从xfsprogs的4.17.0-2.el8开始。
Rad Hat有一篇技术介绍文档 :
XFS已经被验证可以支持极高的企业级伏在，也能够在多线程、并发I/O负载下良好工作；但是XFS在单线程、元数据密负载环境下性能不佳：例如，在单线程情况下创建或删除大量的小文件。详细有关文件系统、文件和目录的限制，请参考 文档的File systems and storage章节。
这意味着企业级数据存储需要有效的存储增强技术。
