问题描述
集群经历了重启后,发现一个诡异的现象:
(1) DownloaderHuabei 和 DownloaderHuabei_bak是同一级目录,执行 ls -l DownloaderHuabei , 出现 DownloaderHuabei_bak no such file or dir
(2) 在挂载点删除DownloaderHuabei_bak目录,删除不掉,文件会自动恢复
(3)DownloaderHuabei_bak目录下也有一个DownloaderHuabei_bak目录,并且这个目录不能操作,ls |grep 会显示很多问号
(4)查看brick的日志
(5)集群中有很多要治愈的文件,经过确定要治愈的文件也是 DownloaderHuabei_bak下的
(6)brick中DownloaderHuabei下并没有DownloaderHuabei_bak
(7)brick 下的日志有 inode: detected cyclic loop formation during inode linkage.
我的解决办法
首先之所以 ls DownloaderHuabei 会显示DownloaderHuabei_bak, 是因为这两个目录的gfid是一样的
# file: DownloaderHuabei_bak
trusted.afr.nsftpVolume-client-0=0x000000000000000100000001
trusted.gfid=0x2386f0cabf7842c3a54c14699f2c6491
trusted.glusterfs.mdata=0x01000000000000000000000000619fe497000000002b6c589200000000619fe497000000002b6c589200000000619fe4a8000000000ab5187c
我的解决办法是:
(1)通过 getfattr -m . -d -e hex <目录名>, 获取到GFID
(2) 将所有brick下有问题的目录(具有相同GFID的目录)删除掉,删除前最好记录一下目录的属组和属主,以及权限,方便后面重建
(3)将gfid-link文件删除掉, 比如 2386f0cabf7842c3a54c14699f2c6491, 要删除掉 ./glusterfs/23/86/2386f0cabf7842c3a54c14699f2c6491
(4) 在挂载点重建目录
(5) 最后就是处理一下要治愈的文件
1、./gluster volume heal nsftpVolume info 获取所有文件
2、源文件已经在上面被我们删除了,我此时删除一下gfid-link文件即可
3、删除gfid-link文件的同时,也要把 .glusterfs/indices/xattrop/${gfid} 删除掉
题外话
我通过上面方式解决的问题。如果大家有更好的办法,请留言,谢谢。