我们团队目前正在决定是否对cephfs目录实现快照，从而尝试了解快照对集群造成的影响和性能问题。
我们主要关心的是“当数据写入快照下的文件时，会对集群产生怎样的影响？”。我们能够发现Ceph使用Copy-on-write机制来克隆快照，所以我的问题是，例如，如果我在快照下有一个1GB的文件，并且我将另外10MB的数据追加到该文件中，那么由于新的写入，将复制多少数据？
我的理解是，由于Ceph将一个文件条带化为多个对象，因此只有包含最后一个stripe_unit的对象（假设它没有完全填充）将被复制，并且新数据将被添加到其中，然后Ceph以某种方式设法包含新数据当我请求当前版本文件时，将包含旧对象，当我从快照请求文件时，将包含旧对象。复制的数据= O(10MB)，我的意思是它是按照数据写入的顺序排列的，并且有一些元数据发生了变化。
或者Ceph现在使用Bluestore作为存储层，是否有更好的优化（与上面的情况相比），比如编辑最后一个stripe_unit对应的对象时，ceph会不会直接将新数据写入磁盘中的某个位置编辑对象的元数据以包含新数据的位置，并维护基于快照的元数据版本，以便为我们提供之前时间点的文件内容。复制/写入的数据 = 10MB 以及更多元数据更改（与上述情况相比）。
或者 Ceph 将复制整个文件并编辑文件的新副本，即复制的数据为 1GB + 10MB。我假设情况并非如此，因为对于大文件来说这显然不是最佳选择。
PS：任何有关衡量快照对集群影响的资源以及任何解释 Ceph 快照内部结构的资源都将非常感激。我在互联网上进行了大量搜索，但找不到任何相关数据。尝试阅读代码，但你们可能猜到它是如何进行的。
我创建了测试池，以便可以测量每个池的消耗，并重复上传相同的 xml 文件，仅在文件末尾为同一文件的每个新版本添加 1 个字节。文件大小为 5MB。对象大小为 50k。
我每次保存新版本后都会制作一个新快照。我注意到，虽然 cephfs 报告目录大小 (df) 没有变化，但池报告消耗量增加了 n 倍。具有 5 个不同版本的 5MB 文件需要 25MB 的池空间用于快照（5 个用于 cephfs 中的最新版本，20 个用于快照中的其他 4 个版本的文件）。
这意味着虽然只附加了一小部分，但每个新版本都会保存整个文件的副本。如果您有很多变化很大的大文件，这是一个坏消息。我将使用更大的文件进行测试并发布更新。