前言
在很久以前在研究一套文件系统的时候,当时发现一个比较奇怪的现象,没有文件存在,磁盘容量还在增加,在研究了一段时间后,发现这里面有一种比较奇特的处理逻辑
这套文件系统在处理一个文件的时候放入的是一个临时目录,最开始在发送第一个写请求后,在操作系统层面马上进行了一个delete操作,而写还在继续,并且需要处理这个数据的进程一直占着的,一旦使用完这个文件,不需要做处理,这个文件就会自动释放掉,而无需担心临时文件占用空间的问题
在Ceph集群当中,有人碰到了去后台的OSD直接rm一个对象后,在前端通过rados还能get到这个删除的对象,而不能rados ls到,我猜测就是这个原因,我们来看下怎么验证这个问题
验证步骤
准备测试数据,并且put进去集群
[root@lab8106 ~]# cat zp1
sdasdasd
[root@lab8106 ~]# rados -p rbd put zp1 zp1
[root@lab8106 ~]# rados -p rbd ls
zp1
找到测试数据并且直接 rm 删除
[root@lab8106 ~]# ceph osd map rbd zp1
osdmap e90 pool 'rbd' (3) object 'zp1' -> pg 3.43eb7bdb (3.1b) -> up ([0], p0) acting ([0], p0)
[root@lab8106 ~]# ll /var/lib/ceph/osd/ceph-0/current/3.1b_head/DIR_B/DIR_D/zp1__head_43EB7BDB__3
-rw-r--r-- 1 ceph ceph 9 Apr 19 14:46 /var/lib/ceph/osd/ceph-0/current/3.1b_head/DIR_B/DIR_D/zp1__head_43EB7BDB__3
[root@lab8106 ~]# rm -rf /var/lib/ceph/osd/ceph-0/current/3.1b_head/DIR_B/DIR_D/zp1__head_43EB7BDB__3
尝试查询数据,get数据
[root@lab8106 tmp]# rados -p rbd ls
[root@lab8106 tmp]# rados -p rbd get zp1 zp1
[root@lab8106 tmp]# cat zp1
sdasdasd
可以看到数据确实可以查询不到,但是能get下来,并且数据是完整的
验证我的猜测
[root@lab8106 tmp]# lsof |grep zp1
ms_pipe_w 4737 5620 ceph 86u REG 8,33 9 201496748 /var/lib/ceph/osd/ceph-0/current/3.1b_head/DIR_B/DIR_D/zp1__head_43EB7BDB__3 (deleted)
···
可以看到这个标记为delete的对象就是我们删除的zp1,这个输出的意思是,进程4737上面删除了一个文件,文件描述符为86的
我们直接去拷贝下这个数据看下
[root@lab8106 tmp]# cp /proc/4737/fd/86 /tmp/zp_save
[root@lab8106 tmp]# cat /tmp/zp_save
sdasdasd
可以看到这个数据确实是存在的,还没有释放,所有可以get的到
我们试下重启下这个进程,看下delete的文件是不是会释放
[root@lab8106 tmp]# systemctl restart ceph-osd@0
[root@lab8106 tmp]# lsof |grep zp1
可以看到已经没有这个delete了,现在我们尝试下get
[root@lab8106 tmp]# rados -p rbd get zp1 zp1
error getting rbd/zp1: (2) No such file or directory
可以看到文件释放掉了,问题确实跟我猜测的是一致的,当然这并不是什么问题
总结
本篇是对删除了的对象还能get的现象进行了解释
变更记录
Why | Who | When |
---|---|---|
创建 | 武汉-运维-磨渣 | 2017-04-19 |