4.3. Ceph 文件系统
用户空间 Ceph 文件系统(CephFS)在升级后按预期工作
在以前的版本中，用户空间 CephFS 客户端有时会在集群升级过程中崩溃。这是因为在用户空间端持有的 MDS 端的过时的功能位。
在这个版本中，确保用户空间 CephFS 客户端已更新了 MDS 功能位，允许客户端在集群升级后按预期工作。
blocklist 和 eviction 客户端以获取大型会话元数据
在以前的版本中，MDS 中的大型客户端元数据构建有时会导致 MDS 切换到只读模式。
在这个版本中，导致构建被阻塞并被驱除的客户端，允许 MDS 按预期工作。
取消链接和重新集成请求之间不再出现死锁
在以前的版本中，当修复 async dirop 错误时，以前的提交引入了一个回归问题，从而导致 unlink 和 reintegration 请求之间的死锁。
在这个版本中，旧提交会被恢复，未链接和重新集成请求之间没有死锁。
客户端始终向 MDS 守护进程发送一个大写的撤销确认
在以前的版本中，当 MDS 守护进程向客户端发送一个大写的撤销请求时，如果客户端释放了上限并删除内节点，则客户端会直接丢弃请求，但 MDS 守护进程需要等待客户端中的大写撤销确认。因此，即使不需要大写的撤销，MDS 守护进程将继续等待来自客户端的确认，从而导致 MDS 守护进程健康状态警告。
在这个版本中，客户端总是向 MDS 守护进程发送一个大写的撤销，即使不存在内节点，MDS 守护进程不再卡住。
MDS 锁定以正确顺序获取
在以前的版本中，MDS 会以错误的顺序获取元数据树锁定，从而导致 create 和 getattr RPC 请求死锁。
在这个版本中，锁定会按照 MDS 中的正确顺序获得，请求不再死锁。
从 CephFS MDS 中跳过发送 split_realms 信息
在以前的版本中，split_realms 信息会错误地从 CephFS MDS 发送，它不能被 kclient 正确解码。因此，客户端不会关注 split_realms，并将其视为一个损坏的 snaptrace。
在这个版本中，split_realms 不会发送到 kclient，且不会发生崩溃。
设置 写 标记后，快照数据不再丢失
在以前的版本中，在客户端中，如果在使用 Fb caps 时将写入标记设置为 '1'，则会在任何脏上限时跳过，并重复使用现有的 capsnap，这是不正确的。因此，连续两个快照会被覆盖并丢失数据。
在这个版本中，写入 标记会被正确设置，不会丢失快照数据。
线程重命名不再失败
在以前的版本中，在一些罕见的情况下，在重命名过程中，如果另一个线程试图查找 dst dentry，则可能会导致它出现不一致的结果，其中 src dentry 和 dst dentry 同时链接到同一内节点。因此，重命名请求将失败，因为两个不同的 dentry 已链接到同一内节点。
在这个版本中，线程会等待重命名操作完成，所有操作都可以正常工作。
吊销请求不再卡住
在以前的版本中，在撤销请求前，这会增加 'seq'，如果客户端释放了对应的上限，并且使用旧 seq 发送 cap update 请求，MDS 会错过检查 seq(s)和 cap 计算。因此，撤销请求会无限期卡住，并会抛出有关撤销请求不会从客户端响应的警告。
在这个版本中，会始终为撤销请求发送一个确认，它们不会再卡住。
在 MDLog::_recovery_thread中安全处理错误
在以前的版本中，如果 MDS 已因为 QA 测试发布的 fs 失败而被阻止，则写入将失败。例如，由于此原因，QA test_rebuild_moved_file (tasks/data-scan)将失败。
在这个版本中，写入失败会在 MDLog::_recovery_thread 中安全处理。
Ceph 客户端现在在发送警报前验证滞后的原因
在以前的版本中，Ceph 有时会发送 laggy OSD 的假警报警告。例如，由于 laggy OSD 而 X 客户端 laggy。这些警报在不验证因为 OSD 实际上是因为 OSD 造成的，而不是因为其他原因而发送。
在这个版本中，仅当某些客户端和 OSD 为 laggy 时，仅当一些客户端和 OSD 为 laggy 时，X 客户端会因为 laggy OSD 消息发出。
