CephFS 快照（pacific版本）

CephFS 支持快照，通常通过在 .snap目录中调用 mkdir 创建。请注意，这是一个隐藏的特殊目录，在目录列表中不可见。

1. OVERVIEW

通常，快照会像听起来那样做：它们在拍摄时创建文件系统的不可变视图。CephFS 快照的一些重要特性与您的预期不同：

• 任意子树。快照在您选择的任何目录中创建，并覆盖该目录下文件系统中的所有数据。

• 异步。如果您创建快照，缓冲的数据会被延迟刷新，包括来自其他客户端的数据。因此，“创建”快照非常快。

2. 重要的数据结构

• SnapRealm：只要您在层次结构中的新点创建快照（或者，当快照的 inode 移出其父快照时），就会创建SnapRealm 。SnapRealms 包含一个 sr_t srnode 和 inodes_with_caps ，它们是快照的一部分。客户端还有一个 SnapRealm 概念，它维护的数据较少，但用于将SnapContext与每个打开的文件关联起来以进行写入。

• sr_t：sr_t是磁盘快照元数据。它是包含目录的一部分，包含序列计数器、时间戳、关联快照 ID 列表和past_parent_snaps。

• SnapServer：SnapServer 管理快照ID分配、快照删除和文件系统中有效快照的跟踪列表。一个文件系统只有一个 snapserver 实例。

• SnapClient：SnapClient 用于与 snapserver 通信，每个 MDS rank 都有自己的 snapclient 实例。SnapClient 还会在本地缓存有效的快照。

3. 创建快照

CephFS 快照功能在新文件系统上默认启用。要在现有文件系统上启用它，请使用以下命令。

$ ceph fs set <fs_name> allow_new_snaps true

启用快照后，CephFS 中的所有目录都会有一个特殊 .snap目录。（如果您愿意，可以使用client snapdir设置配置不同的名称。）

要创建 CephFS 快照， 请使用您选择的名称创建一个.snap子目录。例如，要在目录“/1/2/3/”上创建快照，调用mkdir /1/2/3/.snap/my-snapshot-name。

这作为带有 CEPH_MDS_OP_MKSNAP 标记的MClientRequest传输到 MDS 服务器，最初在 Server::handle_client_mksnap() 中处理。它从 SnapServer 分配一个 snapid，用新的SnapRealm投射一个新的 inode，然后像往常一样将它提交到 MDLog。提交时，它会调用 MDCache::do_realm_invalidate_and_update_notify()，它会通知所有客户端在“/1/2/3/”下的文件上限有关新的 SnapRealm。当客户端收到通知时，他们会更新客户端 SnapRealm 层次结构，将“/1/2/3/”下的文件链接到新的 SnapRealm 并为新的 SnapRealm 生成SnapContext。

请注意，这不是快照创建的同步部分！

4. 更新快照

如果您删除快照，则会执行类似的过程。如果从其父 SnapRealm 中删除一个 inode，重命名代码会为重命名的 inode 创建一个新的 SnapRealm（如果 SnapRealm 不存在），将在原始父 SnapRealm 上有效的快照 ID 保存到新SnapRealm的 past_parent_snaps 中，然后遵循类似于创建快照的过程。

5. 生成 SNAPCONTEXT

RADOS SnapContext由快照序列 ID ( snapid ) 和对象已经属于的所有快照 ID 组成。为了生成该列表，我们将与SnapRealm关联的 snapid 和past_parent_snaps中的所有有效 snapid 结合起来。过时的 snapid被 SnapClient 缓存的有效快照过滤掉。

6. 存储快照数据

文件数据存储在 RADOS “自我管理”快照中。客户端在将文件数据写入 OSD 时要小心使用正确的SnapContext 。

7. 存储快照元数据

快照的 dentry（及其 inode）作为它们在快照时所在目录的一部分内嵌存储。所有的dentries 都包括它们对其有效的第一个和最后一个snapid。（非快照的 dentries 将其最后设置为 CEPH_NOSNAP）。

8. 快照回写

有大量代码可以有效地处理回写。当客户端收到MClientSnap消息时，它会更新本地SnapRealm 表示及其到特定Inode的链接，并为Inode生成CapSnap。CapSnap作为功能回写的一部分被刷新，如果有脏数据，CapSnap用于阻止新数据写入，直到快照完全刷新到 OSD。

在 MDS 中，我们生成代表快照的目录，作为刷新它们的常规过程的一部分。具有出色CapSnap数据的条目会被固定并保存在日志中。

9. 删除快照

快照通过在它们根目录的“.snap”目录上调用“rmdir”来删除。（尝试删除根快照的目录将失败；您必须先删除快照。）一旦删除，它们将进入 OSDMap列表被删除的快照和文件数据被 OSD 删除。当目录对象被读入和写回时，元数据被清理。

10. 硬链接

具有多个硬链接的 Inode 被移动到一个虚拟的全局 SnapRealm。虚拟 SnapRealm 覆盖文件系统中的所有快照。将为任何新快照保留 inode 的数据。这些保留的数据将涵盖 inode 的任何链接上的快照。

11. 多个文件系统

快照和多个文件系统不能很好地交互。具体来说，每个MDS集群独立分配snapid；如果您有多个文件系统共享一个池（通过命名空间），它们的快照会发生冲突，删除一个会导致其他文件数据丢失。（这甚至可能是不可见的，不会向用户抛出错误。）如果每个 FS 都有自己的池，那么事情可能会起作用，但这没有经过测试，可能不是真的。