CephFS 快照

CephFS 支持快照，通常通过在目录内调用 mkdir 来创建。请注意这是一个隐藏的特殊目录，在目录列表中不可见。.snap目录。如果你希望使用不同的名称，可以使用设置进行配置。

概述

通常，快照的作用就像它们的名字一样：它们在快照创建的时间点创建文件系统的不可变视图。有一些引人注目的特性使得 CephFS 快照与你的预期不同：

任意的子树。快照可以在你选择的任何目录内创建，并覆盖该目录下文件系统中的所有数据。
异步的。如果你创建一个快照，缓冲数据会懒惰地刷新出来，包括来自其他客户端的数据。因此，“创建”快照非常快。

重要数据结构

SnapRealm: 一个SnapRealm每当你在新层次结构中创建快照时（或者当快照的 inode 被移动到其父快照之外时）都会创建一个 SnapRealm。SnapRealms 包含一个sr_t srnode, and inodes_with_caps它们是快照的一部分。客户端也有一个 SnapRealm 概念，它维护的数据较少，但用于将一个SnapContext与每个打开的文件关联起来用于写入。
sr_t: 一个sr_t是磁盘上的快照元数据。它是包含目录的一部分，包含序列计数器、时间戳、关联快照 ID 的列表以及past_parent_snaps.
SnapServer: SnapServer 管理快照 ID 的分配、快照的删除，并跟踪文件系统中有效的快照列表。每个文件系统只有一个 SnapServer 实例。
SnapClient: SnapClient 用于与 SnapServer 通信，每个 MDS 等级都有自己的 SnapClient 实例。SnapClient 还在本地缓存有效的快照。

创建快照

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

$ ceph fs set <fs_name> allow_new_snaps true

当启用快照时，CephFS 中的所有目录都将有一个特殊的.snap目录。（如果你希望使用不同的名称，可以使用设置进行配置。）client snapdir要创建 CephFS 快照，在

To create a CephFS snapshot, create a subdirectory under .snap下创建一个具有你选择的名称的子目录。例如，要在目录 “/1/2/3/” 上创建快照，请调用mkdir /1/2/3/.snap/my-snapshot-name .

Note

快照名称不能以下划线（‘_’）开头，因为这些名称保留用于内部使用。

Note

快照名称不能超过 240 个字符。这是因为 MDS 在内部使用长快照名称，其格式为：_<SNAPSHOT-NAME>_<INODE-NUMBER>。由于文件名通常不能超过 255 个字符，并且<node-id>需要 13 个字符，因此长快照名称最多可以占用 255 - 1 - 1 - 13 = 240 个字符。

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

Note that this 中的摘要与从 a synchronous part of the snapshot creation!

更新快照

If you delete a snapshot, a similar process is followed. If you remove an inode out of its parent SnapRealm, the rename code creates a new SnapRealm for the renamed inode (if SnapRealm does not already exist), saves IDs of snapshots that are effective on the original parent SnapRealm into past_parent_snaps of the new SnapRealm, then follows a process similar to creating snapshot.

生成 SnapContext

A RADOS SnapContext consists of a snapshot sequence ID (snapid) and all the snapshot IDs that an object is already part of. To generate that list, we combine snapids associated with the SnapRealm and all valid snapids in past_parent_snaps. Stale snapids are filtered out by SnapClient’s cached effective snapshots.

存储快照数据

File data is stored in RADOS “self-managed” snapshots. Clients are careful to use the correct SnapContext when writing file data to the OSDs.

存储快照元数据

Snapshotted dentries (and their inodes) are stored in-line as part of the directory they were in at the time of the snapshot. All dentries include a first和last snapid for which they are valid. (Non-snapshotted dentries will have their last set to CEPH_NOSNAP).

快照回写

There is a great deal of code to handle writeback efficiently. When a Client receives an MClientSnap message, it updates the local SnapRealm representation and its links to specific Inodes, and generates a CapSnap for the Inode一起使用。该CapSnap会作为能力回写的一部分被刷新出来，如果有脏数据，则使用CapSnap来阻止新的数据写入，直到快照完全刷新到 OSDs。

在 MDS 中，我们作为常规刷新过程的一部分生成表示快照的 dentries。具有未完成的CapSnap数据的 dentries 会被固定并保持在日志中。

删除快照

快照通过在其根目录的 “.snap” 目录上调用 “rmdir” 来删除。（尝试删除根目录为快照的目录将会失败；你必须先删除快照。）一旦删除，它们会被进入已删除快照的列表，并且文件数据会被 OSDs 删除。元数据会在目录对象被读取并写回时清理。OSDMap list of deleted snapshots and the file data is removed by the OSDs. Metadata is cleaned up as the directory objects are read in and written back out again.

硬链接

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

多文件系统

快照和多文件系统交互不佳。具体来说，每个 MDS 集群独立分配snapids；如果你有多个共享单个池（通过命名空间）的文件系统，它们的快照将会发生冲突，删除一个会导致其他文件数据丢失。（这可能甚至是不明显的，不会向用户报错。）如果每个文件系统都有自己的池，可能一切都会正常，但这没有经过测试，可能也不正确。

Note

为了避免 mon-managed 快照和文件系统快照之间的快照 ID 冲突，带有 mon-managed 快照的池不允许连接到文件系统。此外，已经连接到文件系统的池中也不能创建 mon-managed 快照。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.