这是Ceph开发每周谈的第五篇文章，记录从16年1月4号到16年1月10号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
假期归来，Sage 又重新号召所有的 RADOS 各厂商主要开发者参加 Core Standup。在这周，Sage Weil 正式合并 BlueStore 到主干，根据 Mark 最新的性能测试结果显示，对于普通 SATA SSD 的性能提升超出了预期，相信在 Jewel 版应该能达到测试试用程度。
BlueStore
在第一篇就提到过，BlueStore 是一个基于 RocksDB 和 BlueFS 的实现，BlueFS 基于裸设备模拟出一个简易的用户态文件系统使得 RocksDB 能够运行其上。由于 RocksDB 和 BlueFS 两者都在 BlueStore 的控制下，并且可根据需要随时进行修改，因此 BlueStore 彻底避免了之前 XFS 和 RocksDB 的联动日志问题，BlueFS 依赖于 RocksDB 实现元数据管理但同时又承接了 RocksDB 从 BlueStore 调用的 xattr 和 omap 实现，因此，就像 Sage 之前提到的 XFS metadata 和 RocksDB log 的冗余写，BlueFS 自身降级使得这个问题得以避免。
上周 Javen Wu 提到了 ZFS 作为一个成熟的文件系统是不是可以直接利用 libzpool 去实现一个用户态的 zfs library，而不是实现一个简陋的 BlueFS。在这一方面，Sage 认为 userspace 的 zfs 和 kernel 的 xfs 本身没有本质区别，因为 RocksDB 的 LSM 结构是必不可少的，因此必须在文件系统级别进行让步，那 zfs 只能进一步弱化。
NFS on Ganesha
Ganesha 是著名的用户态 NFS 服务器端实现，目前支持 NFS.0, 3.0, 4.0,4.1 协议，通过后端 FSAL 的驱动，Ganesha 可以支持多种不同的文件系统后端，如 CephFS，Lustre，ZFS，GPFS，GlusterFS 等等，cohortfs 是之前在这个领域的主要推动者，不过最近也被 Redhat 收购了。cohortfs 原班人马加入 Ceph 社区后，仍然会致力于推动高性能的 Ceph 集群工作以及 CephFS 的用户场景实现。在最近的用户测试中，发现最大的问题仍然是大量文件下，MDS 与 Ganesha 的不协调，比如 Ganesha 所允许的 inode cache 会大大超出 cephfs mds 所允许配置的。另外 uid/gid 问题当使用其他 kerbetos 进行认证时也会出现乱码的问题。不过 Matt 和 Adam 都已经承诺在下一个版本修复这些问题。
还有一些用户关心 Ganesha HA 来实现 NFS Server HA 的问题，但是根据 Sage 在 Tokyo Summit 的 VM on NFS 讨论，指出 Ganesha 依赖网络 VIP 如 corosync + keepalived 会造成 MDS Session 在切换时出错从而数据紊乱问题，因此仅推荐 NFS 单机使用。
NFS in VM
既然聊到 NFS，那么就继续 Ceph 社区在扩展 VM 使用 NFS 的场景，之前 Sage Weil 短暂同意推动 CephFS + VirtFS 的方式推动 VM Filesystem 服务，扩大 CephFS 的用户场景，后来随着 vsock 和 cohortfs 的推动，Sage Weil 转而期望利用 vsock 这个通用并且活跃的 VM <-> Host 通道，vsock 允许 NFS 客户端和服务器端做少量改动(修改网络系统调用)即可完成 NFS 协议基于 vsock 的传输。但是这个方式的问题是遥遥无期，因此，有些用户同样利用这个方式使用 NAT + NFS 来导出 VM 的 NFS 包到 Host 的 NFS Server，这个方案的优点在于迅速满足所有之前的可用性问题，缺点在于 NAT 方式会有一定的安全隐患。