【Ceph】Ceph快照的原理和实现--未消化

快照原理

1、先了解一下文件系统的知识

https://blog.csdn.net/bandaoyu/article/details/125375996?spm=1001.2014.3001.5501

2、快照原理

https://blog.csdn.net/bandaoyu/article/details/120421383

http://t.csdn.cn/8xrIS

实现

原文：https://docs.ceph.com/en/quincy/dev/cephfs-snapshots/

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

1. OVERVIEW

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

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

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

2. 重要的数据结构

• SnapRealm：

  每当您在新的位置创建快照时(或当快照索引节点移动到其父快照之外时)，都会创建SnapRealm。SnapRealms包含一个sr_t srnode，以及作为快照一部分的inodes_with_caps。客户端也有一个SnapRealm概念，它维护的数据较少，但用于将SnapContext与每个打开的文件关联起来for写入。

• sr_t：sr_t是磁盘快照元数据。它是containing目录的一部分，包含序列计数器、时间戳、关联快照 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，利用新的 SnapRealm创建并链接一个新的inode，然后将其提交到 MDlog，提交后会触发 MDCache::do_realm_invalidate_and_update_notify()，此函数将此 SnapRealm广播给所有对快照目录下任一文件有管辖权的客户端。它会通知所有客户端在“/1/2/3/”下的文件上限有关新的 SnapRealm。

客户端收到通知后，将同步更新本地 SanpRealm层级结构，并为新的SnapRealm结构生成新的 SnapContext，用于将快照数据写入 OSD 端。同时，快照的元数据会作为目录信息的一部分更新到OSD端(即sr_t)。整个过程是完全异步处理的。

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

To create a CephFS snapshot, create a subdirectory under <span class="pre">.snap</span> with a name of your choice. For example, to create a snapshot on directory “/1/2/3/”, invoke <span class="pre">mkdir</span><span> </span><span class="pre">/1/2/3/.snap/my-snapshot-name</span> .

This is transmitted to the MDS Server as a CEPH_MDS_OP_MKSNAP-tagged MClientRequest, and initially handled in Server::handle_client_mksnap(). It allocates a snapid from the SnapServer, projects a new inode with the new SnapRealm, and commits it to the MDLog as usual. When committed, it invokes MDCache::do_realm_invalidate_and_update_notify(), which notifies all clients with caps on files under “/1/2/3/”, about the new SnapRealm. When clients get the notifications, they updat