xfs文件系统修复 superblock sb agf agi agfl

我们在排查问题的过程中，经常会遇到需要修复文件系统的场景，这类问题处理前需要对文件系统的结构有一定了解。本文主要总结一些xfs文件系统的结构。

1. xfs文件系统大体结构

先看下下面这个图，图中可以看到xfs是由多个AG组成的，每个AG可以看做是一个独立的文件系统，默认AG数量是4个，这个可以在mkfs的时候指定。

2. AG的结构

下图是一个AG的结构，整个文件系统的空闲空间和所有inode数量只由第一个AG（primary）维护。 每个AG都是以superblock开始。AG0的主超级志（primary superblock）保存了所有AG信息。其它AG的superblock仅当主超级块损坏时，通过xfs_repair修复会用到。超级块占用一个扇区的大小(512字节)

超级块里面的信息非常多，具体定义是在内核代码\fs\xfs\libxfs\xfs_format.h中的xfs_sb部分，这里就不一一展开了。 在主机内，我们可以通过xfs_db 命令查看到，如图。

• magicnum 指的是文件系统的开始，每个文件系统标识符不一样，xfs这里是0x58465342
• blocksize 块大小，最小空间分配的单位大小，默认是4096，格式化文件系统的时候也是可以指定的
• uuid 文件系统的UUID，也就是blkid 命令看到的这个UUID，可以用UUID来进行挂载
• agblocks AG中的块数量
• agcount AG的数量，默认是4
• logblocks 日志用的块数量
• sectsize 扇区大小，默认是512
• inodesize inode大小，默认是256
• icount：文件系统可分配的inode总数量，只在第一个超级块里维护
• ifree：文件系统空闲的inode总数量，只在第一个超级块里维护
• fdblocks：文件系统空闲数据块的总数量，，只在第一个超级块里维护
• frextents：文件系统空闲实时extent的总数量，只在第一个超级块里维护

3. superblock的修复案例

3.1 现象

收到客户反馈，在扩容过程中可能存在误操作，导致原来能挂载的xfs磁盘不能正常挂载，报错信息如图：

进一步查看dmesg日志可以看到超级块不可用

3.2 排查

从上面的信息我们可以知道，超级块是在第一个扇区(512字节)，那么我们现在看下第一个扇区中内容是什么，如图。

正常xfs的SB开头应该是XFSB，看到这里至少证明superblock已经损坏。接下来我们看下后面几个扇区的内容是否有问题。

superblock后面三个扇区看起来都是正常的，文件系统正常的结构都还存在。接下来我们尝试下 修复SB，看下能不能成功。

3.3 修复

目前现象看到只是superblock损坏，那我们直接尝试xfs_repair修复看下，稳妥起见还是用xfs_repair -n 只读模式先检查看下。

这里一直卡在查找secondary superblock位置，难道其他AG的superblock也损坏了吗

从前面xfs的结构可以知道因为xfs默认是分成4个AG的，每个AG都有维护superblock，当前这个vdc磁盘总大小是107374182400 bytes，那么正常情况下AG1 就应该是107374182400/4=26843545600bytes的位置开始 偏移512字节应该是AG1的SB。我们来看下这里是否有superblock。

从这里我们找到了其他AG是存在superblock的，那么xfs_repair 为何长时间查找没有结果呢。接下来看下xfs_repair的源码。 这里centos7中的rpm包xfsprogs版本最新是4.5.0-22.el7.x86_64，查看4.5版本的源码，查找secondary superblock的方法是在sb.c文件中的find_secondary_sb函数，从代码中可以看到是每次读取1兆的数据，然后检查sb是否存在。 在知道xfs结构和AG分布的情况下，这种方法比较简单粗暴，同时也会很耗时，磁盘特别大的话 会花费很长时间扫描。

xfsprogs官方最新是5.0，查看最新源码，这里已经调整了代码逻辑，最新版本会先对偏移量进行猜测和计算，最终都失败才会去走4.5版本中的方法。

使用5.0版本的xfsprogs编译后，执行xfs_repair果然很快就找到了superblock，尝试修复执行后修复成功。

转载至

xfs文件系统修复 - 知乎