xfs的故障记录
##前言 我使用xfs比较二一点，我是在ceph的rbd上直接格式化的xfs，所以ceph上的数据一般不会丢失，不过我的xfs是在docker内部进行的挂载，使用也是docker容器内使用，这里不得不说docker stop容器的时候还是相当的暴力，暴力到什么程度呢？xfs大多会在硬盘突然断电的情况下导致日志文件的写入损坏，故障往往就在这时发生，而docker stop容器和突然断电可以画上等号。最为悲催的是，我刚开始对xfs一无所知。ceph的rbd也是一知半解。而数据是万万不能丢失的，所以中间折腾了好长时间。
###故障现象 marathon上是无法停止或者无法启动容器的，容器进程实际已经卡死，登录到后台，kill进程已经没有意义了，压根就不起作用。 message报错如下：
Sep 19 10:05:44 [localhost] kernel: XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1590 of file /builddir/build/BUILD/kernel-tlinux2-3.10.101/kernel-tlinux2-3.10.101/fs/xfs/xfs_alloc.c. Caller 0xffffffff8130fadd
Sep 19 10:05:44 [localhost] kernel: CPU: 1 PID: 5826 Comm: mount Tainted: G W O 3.10.101-1-tlinux2-0037.tl2 #1
Sep 19 10:05:44 [localhost] kernel: Hardware name: Huawei XH310 V3/BC21DUSA0, BIOS 1.13 09/19/2015
Sep 19 10:05:44 [localhost] kernel: ffff8803f5aa4000 000000006315a611 ffff8803fc2f5b00 ffffffff81b2a080
Sep 19 10:05:44 [localhost] kernel: ffff8803fc2f5b18 ffffffff812f563b ffffffff8130fadd ffff8803fc2f5bc0
Sep 19 10:05:44 [localhost] kernel: ffffffff8130e008 ffff8803fa40c000 ffff8803fe56b000 ffff8803fe508480
Sep 19 10:05:44 [localhost] kernel: Call Trace:
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81b2a080>] dump_stack+0x19/0x1b
Sep 19 10:05:44 [localhost] kernel: [<ffffffff812f563b>] xfs_error_report+0x3b/0x40
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8130fadd>] ? xfs_free_extent+0x12d/0x170
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8130e008>] xfs_free_ag_extent+0x458/0x970
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8130fadd>] xfs_free_extent+0x12d/0x170
Sep 19 10:05:44 [localhost] kernel: [<ffffffff813508c0>] xlog_recover_process_efi+0x1a0/0x1e0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81367154>] ? xfs_trans_ail_cursor_init+0x24/0x30
Sep 19 10:05:44 [localhost] kernel: [<ffffffff813525b2>] xlog_recover_process_efis.isra.18+0x72/0xd0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81356471>] xlog_recover_finish+0x21/0xb0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81360704>] xfs_log_mount_finish+0x54/0x70
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81359924>] xfs_mountfs+0x474/0x740
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81307479>] xfs_fs_fill_super+0x299/0x320
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81173908>] mount_bdev+0x1b8/0x1f0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff813071e0>] ? xfs_parseargs+0xc40/0xc40
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81305595>] xfs_fs_mount+0x15/0x20
Sep 19 10:05:44 [localhost] kernel: [<ffffffff811741e5>] mount_fs+0x15/0xc0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8118da1f>] vfs_kern_mount+0x5f/0xf0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8118fe6d>] do_mount+0x21d/0xab0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff8111003e>] ? __get_free_pages+0xe/0x50
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81190796>] SyS_mount+0x96/0xf0
Sep 19 10:05:44 [localhost] kernel: [<ffffffff81c0cce2>] system_call_fastpath+0x16/0x1b
Sep 19 10:05:44 [localhost] kernel: XFS (rbd0): Failed to recover EFIs
Sep 19 10:05:44 [localhost] kernel: XFS (rbd0): log mount finish failed一开始没想到会是文件系统损坏，因为没有理太清楚ceph的rbd和xfs之间的关系，其实也没有查到会是xfs出了问题。还是在怀疑ceph的rbd可能什么资源没有释放。 ###怀疑rbd资源未释放 ceph的rbd是有锁的，他要保证数据的一致性，当有一个客户端挂载之后会立即加锁记录到ceph当中。查看锁的方法
[root@localhost /data]# rbd lock ls data/test
There is 1 exclusive lock on this image.
Locker ID Address
client.514151 test 192.168.1.3:0/1002880如果发现列表中有不正常的锁，可以运行下面的命令进行清理：
##命令格式
lock remove <image-name> <id> <locker>
[root@localhost /data]# rbd lock remove data/test test client.514151我也这么干了，但是发现问题依旧，rbd还是挂载不上，容器一启动就卡死，docker连ps都运行不出来，只得带外重启系统才能释放资源、清理进程。为了缩小问题的范围，我开始尝试手动直接挂载rbd，就在做好本地映射准备挂载的时候，提示文件系统报错，无法挂载。这也就是说docker没有问题，应用也正常，ceph -s之后一切也ok，唯一出问题就是在rbd之上的xfs文件系统。 ###恍惚之间的艰难选择 xfs我是一窍不通，我开始压根没太觉得这玩意会天天出问题。网上找了一通之后，开始尝试先恢复数据。 尝试dump rbd的数据：
xfs_metadump -o /dev/rbd0 /data/rbd0.metadump （加-o参数，不然元数据会显示乱码）还原：
xfs_mdrestore rbd0.metadump rbd0.img这个时候尝试进行挂载rbd0.img，发现问题依旧，还是不行，于是开始修复
xfs_repair -L rbd0.img然后挂载，又报错，提示dmesg|tail查问题，其实就是uuid重复的问题，这样挂载就好了：
mount -t xfs -o nouuid rbd0.img /data1/挂载检查之后发现，文件目录和文件名称正常，数据大小也没有问题，但是每个文件中都是空的，根本读不出来具体的数据。 思索再三之后才恍然大悟，原来这玩意仅仅是在dump xfs的元数据，每个文件真实的数据都不包含，你从rbd0.img的大小就能看出来，绝对不是全量的xfs数据。其实xfs全量的dump真正用的命令是xfsdump，同样对应的是xfsrestore,不过挺遗憾的，没有实验这组命令：
xfsdump -l 0 -f /dev/rbd0 /data/dump/具体的使用要看这里 如果你要用xfsdump恢复数据，建议用管道的方式（xfsdump -J -s people/fred - /usr | xfsrestore - /usr2）进行恢复，因为xfsdump需要准备一个额外的同等大小的分区来进行数据还原，而不是仅仅是数据的大小。 其实xfsdump并不适合解决我的问题，百度谷歌一通之后，还是倾向于直接xfs_repair -L，但是-L说会丢失部分日志数据，这个怕是我背不起的。所以在做这个之前，我想先备份一下现有数据。省的我最后的救命稻草没了，就死翘翘了。 ###数据备份 备份有两个办法：
- 借助ceph rbd的导出功能，将整个rbd块全部导出，保存好导出的数据，就可以对原有的rbd快进行repair操作了，这个肯定能成功，而且比较稳妥，问题就是慢，速度不怎么快，毕竟是数据大，网络传输需要时间，另外就是你的rbd块设备总共多大，你导出来的文件就有多大，你得小心这个。
rbd export test test.img- 借助xfs_copy将两个块设备进行数据copy。
xfs_copy /dev/rbd0 /dev/rbd1这个速度要比第一个能高一半，但是目标块设备的大小要大于源块设备，而且文件系统也必须是xfs，不过遗憾的是，这个方式没法用，因为到最后90%的时候它是无论如何也到不了100%的，原因很简单源块设备的文件系统是坏的，xfs_copy只能在两个正常的xfs文件系统中复制数据。所以费了我们好多时间。 ###临终 最终还是直接xfs_repair -L 直接在ceph的源故障块上进行操作修复的。这里附上疑似华为的解决文档作为参考，以后再遇到此故障，放心大胆的搞，传送门 最后，生死由命，富贵在天，你在dump的时候多拜拜春哥：