cephfs实现回收站功能

Question

将mds端unlink请求转为remove请求，remove到一个我们指定的目录，从而实现回收站功能
内核客户端接收消息分发函数fs\ceph\mds_client.c的dispatch函数会调用handle_reply处理回复消息。
handle_reply调用ceph_fill_trace函数在内存中填充inode和dentry的信息。
dmesg报错系统崩溃在ceph_fill_trace函数的BUG_ON(ceph_ino(dir) != dvino.ino)处

        dvino.ino = le64_to_cpu(rinfo->diri.in->ino);
        dvino.snap = le64_to_cpu(rinfo->diri.in->snapid);        
        BUG_ON(ceph_ino(dir) != dvino.ino);
        BUG_ON(ceph_snap(dir) != dvino.snap);

ceph_ino(dir)是内核客户端发送请求到mds端之前存储的ino，dvino.ino是mds回复给内核客户端reply_info中的ino，因为在mds中调用了set_ino对ino更改了，所以这里两者不相同，从而报错 程序崩溃。
将此处注释掉进行测试，测试结果：
程序正常执行，rm删除文件之后，文件加上.bak后缀然后mv到了指定的trash目录中，但是在执行rm操作的目录中，ls卡顿，大概卡顿两分钟之后，ls正常，文件/目录读写正常。

应该怎么修改以实现这个功能呢？

Answer 1

以下内容源自超时代AI智能助手，仅供参考，可行性需要自行评估。

1. 问题分析
   • 核心问题
     • 目前在实现将CephFS的unlink请求转换为remove请求以实现回收站功能的过程中，遇到了内核客户端在ceph_fill_trace函数中的崩溃问题。虽然通过注释掉BUG_ON语句使程序能够继续执行，但出现了ls卡顿的新问题。
     • 卡顿问题可能与文件系统元数据的处理有关。当将文件移动到回收站（trash目录）时，可能是文件系统在更新目录索引或者处理文件状态变化时出现了延迟。
   • 关于ino不匹配的深入探讨
     • 在ceph_fill_trace函数中，ino（索引节点号）的不匹配表明在mds端对ino的修改没有被内核客户端正确处理。这可能是由于消息传递过程中的同步问题或者对ino处理逻辑的不一致导致的。
2. 解决方案建议
   • 修复ino不匹配问题
     • 正确的ino传递逻辑
       • 在mds端修改ino时，需要确保将新的ino值正确地传递给内核客户端。可以在mds端的set_ino函数中添加代码，将修改后的ino值作为回复消息的一部分发送回内核客户端。例如：

         // 在mds端的set_ino函数中
         void set_ino(struct some_struct *obj, uint64_t new_ino) {
         obj->ino = new_ino;
         // 将新的ino值添加到回复消息结构体中
         reply_info->diri.in->ino = cpu_to_le64(new_ino);
         }
         

     • 内核客户端的ino更新
       • 在内核客户端的handle_reply函数中，当接收到包含新ino值的回复消息时，更新本地存储的ino值。修改handle_reply函数如下：

         void handle_reply(struct ceph_mds_client *client, struct ceph_msg *msg) {
         struct ceph_mds_reply_info *rinfo = (struct ceph_mds_reply_info *)msg->front.iov_base;
         // 更新ino值
         dvino.ino = le64_to_cpu(rinfo->diri.in->ino);
         dvino.snap = le64_to_cpu(rinfo->diri.in->snapid);
         // 移除注释后的正确逻辑处理
         if (ceph_ino(dir)!= dvino.ino) {
         // 更新本地存储的ino值为新的值
         ceph_ino(dir) = dvino.ino;
         }
         if (ceph_snap(dir)!= dvino.snap) {
         ceph_snap(dir) = dvino.snap;
         }
         ceph_fill_trace(client, dir, dvino);
         }
         

   • 解决ls卡顿问题
     • 优化元数据更新
       • 在将文件移动到trash目录（mv操作）时，可能会触发大量的元数据更新操作。可以考虑优化这个过程，例如采用批量更新元数据的方式。在CephFS的文件移动操作函数中，可以添加一个缓存机制，将多个元数据更新操作缓存起来，然后一次性进行处理。

         // 假设这是CephFS文件移动操作函数的一部分
         void cephfs_move_file(struct cephfs_file *src, struct cephfs_file *dst) {
         // 缓存元数据更新操作的结构体
         struct metadata_update_cache {
         struct list_head list;
         struct cephfs_metadata_update update;
         };
         struct metadata_update_cache *cache = NULL;
         // 初始化缓存
         INIT_LIST_HEAD(&cache->list);
         // 将文件移动操作涉及的元数据更新添加到缓存
         add_metadata_update_to_cache(cache, &src->metadata);
         add_metadata_update_to_cache(cache, &dst->metadata);
         // 当缓存达到一定数量或者文件移动操作完成后，批量处理元数据更新
         if (cache_is_full(cache) || is_move_complete()) {
         batch_process_metadata_updates(cache);
         }
         // 释放缓存
         free_metadata_update_cache(cache);
         }
         

     • 减少不必要的文件系统扫描
       • 在执行rm操作时，ls卡顿可能是因为文件系统在删除文件后进行了不必要的扫描。可以通过标记文件为已删除（在元数据中），而不是立即进行全面扫描来提高性能。在CephFS的删除文件操作函数中：

         void cephfs_delete_file(struct cephfs_file *file) {
         // 在元数据中标记文件为已删除
         mark_file_deleted_in_metadata(file);
         // 延迟或者按需进行全面的文件系统扫描
         schedule_file_system_scan_later();
         }