Cephfs的文件存到哪里了
前言
在ceph里面使用rbd接口的时候，存储的数据在后台是以固定的prifix的对象存在的，这样就能根据相同的前缀对象去对image文件进行拼接或者修复
在文件系统里面这一块就要复杂一些，本篇就写的关于这个，文件和对象的对应关系是怎样的，用系统命令怎么定位，又是怎么得到这个路径的
实践
根据系统命令进行文件的定位
写入测试文件
dd if=/dev/zero of=/mnt/testfile bs=4M count=10
查看文件的映射
[root@lab8106 mnt]# cephfs /mnt/testfile map
WARNING: This tool is deprecated. Use the layout.* xattrs to query and modify layouts.
FILE OFFSET OBJECT OFFSET LENGTH OSD
0 10000001188.00000000 0 4194304 1
4194304 10000001188.00000001 0 4194304 0
8388608 10000001188.00000002 0 4194304 1
12582912 10000001188.00000003 0 4194304 0
16777216 10000001188.00000004 0 4194304 1
20971520 10000001188.00000005 0 4194304 0
25165824 10000001188.00000006 0 4194304 0
29360128 10000001188.00000007 0 4194304 1
33554432 10000001188.00000008 0 4194304 1
37748736 10000001188.00000009 0 4194304 0
查找文件
[root@lab8106 mnt]# ceph osd map data 10000001188.00000000
osdmap e109 pool 'data' (2) object '10000001188.00000000' -> pg 2.9865f84d (2.d) -> up ([1], p1) acting ([1], p1)
[root@lab8106 mnt]# ll /var/lib/ceph/osd/ceph-1/current/2.d_head/10000001188.00000000__head_9865F84D__2
-rw-r--r-- 1 ceph ceph 4194304 Apr 20 09:35 /var/lib/ceph/osd/ceph-1/current/2.d_head/10000001188.00000000__head_9865F84D__2
根据上面的命令已经把文件和对象的关系找到了，我们要看下这个关系是根据什么计算出来的
根据算法进行文件定位
写入测试文件(故意用bs=3M模拟后台不为整的情况)
[root@lab8106 ~]# dd if=/dev/zero of=/mnt/myfile bs=3M count=10
获取文件的inode信息
[root@lab8106 ~]# fileinode=`stat -c %i "/mnt/myfile"`
[root@lab8106 ~]# echo $fileinode
获取文件的大小和对象个数信息
[root@lab8106 ~]# filesize=`stat -c %s "/mnt/myfile"`
[root@lab8106 ~]# echo $filesize
31457280
[root@lab8106 ~]# objectnumori=`echo "scale = 1; $filesize/$objectsize"|bc`
[root@lab8106 ~]# echo $objectnumori
7.5
[root@lab8106 ~]# objectnum=`echo $((${objectnumori//.*/+1}))`
[root@lab8106 ~]# echo $objectnum
8
获取对象名称前缀
[root@lab8106 ~]# declare -l $objectname
[root@lab8106 ~]# objectname=`echo "obase=16;$fileinode"|bc`
[root@lab8106 ~]# echo $objectname
1000000118b
上面的declare -l操作后，对象名称的变量才能自动赋值为小写的，否则的话就是大写的，会出现对应不上的问题
对象的后缀(后面的0即为编号)
[root@lab8106 ~]#objectbackname=`printf "%.8x\n" 0`
[root@lab8106 ~]#echo $objectbackname
真正的对象名称为：
[root@lab8106 ~]#realobjectback=$objectname.$objectbackname
打印出所有对象名称
[root@lab8106 ~]# for num in `seq 0 $objectnum` ;do backname=`printf "%.8x\n" $num`;echo $objectname.$backname;done;
1000000118b.00000000
1000000118b.00000001
1000000118b.00000002
1000000118b.00000003
1000000118b.00000004
1000000118b.00000005
1000000118b.00000006
1000000118b.00000007
1000000118b.00000008
可以看到用算法进行定位的时候，整个过程都没有跟集群ceph进行查询交互，只用到了获取文件的stat的信息，所以根据算法就可以完全定位到具体的对象名称了
根据对象名称查找文件所在的位置
假如一个对象名称如下：
10000000010.00000003
对象名称取10000000010前面加上0x,并且去掉.后面的，得到:
0x10000000010
计算出inode:
[root@lab8106 mnt]#printf "%d\n" 0x10000000010
1099511627792
根据inode查找文件路径
[root@lab8106 mnt]# find /mnt/ -inum 1099511627792 -printf "%i %p\n"
1099511627792 /mnt/testfile
总结
本篇是介绍了cephfs中文件跟后台具体对象对应的关系，这个对于系统的可恢复性上面还是有很大的作用的，在cephfs当中只要对象还在，数据就还在，哪怕所有的服务全挂掉，这个在之前的某个别人的生产环境当中已经实践过一次，当然那个是rbd的相对来说要简单一些，当然文件系统的恢复也可以用OSD重构集群的方式进行恢复，本篇的对于元数据丢失的情况下文件恢复会有一定的指导作用
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2017-04-20 |
| 增加根据对象查找文件位置 | 武汉-运维-磨渣 | 2017-07-12 |
