Linux上有很多大家耳熟能详的文件系统，比如EXT4、XFS，甚至BTRFS都比openZFS更有名，但是很多40出头的IT人对ZFS还是有一些印象的。许多人认为openZFS有点过时了。就在ZFS准备与LINUX紧密结合的时候，SUN被甲骨文收购，所以这也注定了ZFS前路坎坷。在国外很多IT社区中，ZFS被贴上了“原为Sun，却“得到了Oracled””的标签。“gotOracled”在IT领域并不是一个好词。很多好的技术都被甲骨文收购淘汰了。ZFS与普通文件系统完全不同。它是一个严格一致性的文件系统，是一个日志结构的文件系统。与数据库一样，ZFS依赖于类似WAL的机制来确保文件系统的一致性。因此，ZFS可以随时保持非常强的一致性。有过服务器断电后文件系统挂掉或变成只读的朋友可能还是心有余悸。ZFS上从来不需要fsck，因为WAL可以帮助我们自动纠正这些不一致。ZFS采用COW（COPYONWRITE）的方式修改数据，与SSD的行为类似。这种方式是一把双刃剑，可以在读和写之间获得更好的平衡，但是会带来写放大的问题。数据修改操作会有较高的开销。ZFS的RAID-Z技术堪称穷人的福音。采用RAID-Z技术，可将多块硬盘组合成软RAID系统，保证数据安全。同时ZFS支持数据压缩，可以进一步降低数据的存储成本。ZFS支持非常强大的快照技术，通过快照进行闪回或者克隆数据非常方便。这为数据保护、数据备份、数据复制等提供了非常有力的保障，对于这样一个复杂的文件系统，额外的开销肯定是非常大的。为了保证ZFS的性能，采用了内存修改和强一致性事务存储的方式。如果你的硬件环境好，物理内存比较多，那么在内存中完成写操作，把日志写到性能优异的NVMESSD盘上，把大量数据写到大容量的HDD上，然后当你的写入IO不够大，无法突破内存缓冲区时，ZFS文件系统可以表现出出色的写入性能。对于ZFS的性能问题，网络上有很多不同的密钥，测试结果也各不相同。从更中肯的角度来看，任何好处都是有代价的。ZFS在保证数据安全的前提下肯定会缺乏性能。一些认为ZFS性能差的朋友可能调优没做好，而一些认为ZFS性能很好的朋友可能测试场景单一简单。一般来说，相比于EXT4/XFS等传统文件系统，ZFS在大量持久写场景下的性能肯定要差很多。对于读写比较均衡的OLTP系统，ZFS的性能与EXT4非常接近。略低。在一些OLTP数据库场景下，由于ZFS的内存读写缓冲机制，也可能表现出比EXT4/XFS更好的性能。比如我们在ZFS上运行PG或者MySQL时，因为文件系统可以保证不会出现blockbreak，所以我们可以关闭FULLPAGEWRITE以获得更好的并发性能。这其实就是我昨天讨论的一个例子，把数据库的工作交给OS。其实ZFS的调优并没有那么复杂。如果你有我上面提到的环境，物理内存大，写日志的SSD盘，那么下面的调整方案可能就足以让ZFS发挥出不错的性能了。虽然针对ZFS文件系统的针对性调优比较复杂，因为针对不同的数据保护模式，不同的缓冲策略和压缩策略，都会有非常复杂的配置。不过总的来说，调整并不复杂：lrecordsize=8kB；llogbias=throughput[latency]：可以根据自己的应用场景需求选择throughput和delay。对于并发要求高的OLTP应用，可以选择LATENCY。对于数据扫描分析应用，可以选择吞吐量；lzfs_arc_max：这个参数一定要设置，避免arccache占用过多内存导致操作系统换页。有兴趣的朋友可以找时间试试ZFS的性能是否能满足你的应用需求。我想，在不追求极致性能的情况下，ZFS强大的一致性保证和数据压缩能力，已经可以让我们的数据库系统受益匪浅。目前，openZFS社区非常活跃。今年年初推出的2.1.7版本支持3.10-6.0LINUX内核。相对于不成熟的BTRFS，我还是推荐openZFS。其实我们国内的数据库厂商也可以尝试考虑openZFS，利用这个开源项目为自己的数据库产品开发一个底层存储组件，在自己的数据库一体机上使用。
