Cephfs数据池数据对象命名规则解析

众所周知，cephfs的数据和元数据是分离的，处于不同的pool池里头，而无论是rgw、cephfs、rbd底层的数据池的存储都是基于RADOS(Reliable Autonomic Distributed Object Store),Ceph存储集群的基础，RADOS层的一切都是以对象的形式存储着的，无论上层是文件、对象还是块。

主要说说cephfs的文件在数据池中是如何分布的，下面以cephfs的内核客户端为例进行分析。

以下图文件为例，先找到这个文件的inode号1099511627776，转换为16进制为10000000000，从数据池中找到这个对象，对象的名称为文件的inode号.编号（数据位置/对象大小object_size（默认4M），从0开始编号）

Cephfs读数据转换osd请求

struct ceph_file_layout {
    /* file -> object mapping */
    u32 stripe_unit;   /* stripe unit, in bytes */
    u32 stripe_count;  /* over this many objects */
    u32 object_size;   /* until objects are this big */
    s64 pool_id;        /* rados pool id */
    struct ceph_string __rcu *pool_ns; /* rados pool namespace */
};

文件的layout的属性，位于每个文件的inode属性中，是用来计算文件实际对象分布的条件。

客户端（linux内核客户端）位于文件的扩展属性xattr当中，通过set_xattr流程（客户端入口函数__ceph_setxattr和服务端mds入口函数为Server::handle_client_setxattr）进行修改。

可以使用getxattr命令查看默认值，命令和回显如下：

getfattr -n ceph.file.layout ceph-debuginfo-Lakestor_v2.1.0.18-0.el7.x86_64.rpm

ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 pool=cephfs-data”

读流程从linux内核客户端向osd服务端发起请求：
入口函数为
|__ceph_read_iter
|____ceph_get_caps（获取文件的cap，如果cap不满足条件就发送getattr的req向mds服务端去获取最新的inode元数据，服务端处理完成回请求时客户端使用handle_reply最终fill_inode,将最新的元数据信息填写到客户端inode缓存里）
|______ceph_direct_read_write(如果客户端dcache没有对应位置缓存，就向osd发请求获取)

|__ceph_direct_read_write:
|____ceph_osdc_new_request(calc_layout-|______ceph_calc_file_object_mapping[ceph_oid_printf(&req->r_base_oid, "%llx.%08llx", vino.ino, objnum);])
|________ceph_osdc_start_request
...

|__ceph_osdc_new_request：
|____calc_layout(layout, off, plen, &objnum, &objoff, &objlen)：
|______ceph_calc_file_object_mapping
重要入参:1,inode中的layout结构，2,要写的偏移位置 off和3,要写的长度plen。
出参：1，要写的对象编号objnum，2，对象内的偏移objoff,。
|________ceph_oid_printf(&req->r_base_oid, "%llx.%08llx", vino.ino, objnum);(将inode号.对象编号拼接起来形成要写的对象名)