AIX无法mount之fsck原理解析

1.先来看故障现场：

客户XX一台IBM P550（8204-E8A）小型机CPU、内存扩容完成后，重启主机登陆到系统，发现存储（IBM DS5020）上有部分文件系统无法挂载（此处是应用厂商提供的自动挂载脚本，客户平时启应用都是用这个脚本挂载的，排除脚本问题），报错如下：
# ./mountprd.sh

prdvg是建立在存储映射过来的卷之上，在扩容过程中没有对存储做过任何操作。prdvg能够正常varyonvg和varyoffvg。

尝试手动挂载也挂载不上，机器重启后再试还是不行，报同样的错。

# mount /db2
Replaying log for /dev/lvdb2.
mount: 0506-324 Cannot mount /dev/lvdb2 on /db2:The media is not formatted or the format is not correct.

0506-342 The superblock on /dev/lvdb2 isdirty.  Run a full fsck to fix.

原因分析：
根据报错信息初步判定是文件系统损坏，需要运行fsck命令修复。分析导致文件系统损坏的原因可能是因为中途有非法关机造成的。

解决过程：

在尝试了重启机器和手动挂载、强制挂载都无果的情况下，最终还是选择使用fsck命令冒险一试，完成修复。过程如下：

# fsck -p /dev/lvdb2
The current volume is: /dev/lvdb2
Primarysuperblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
Block allocation map is corrupt (FIXED)
Superblock marked dirty because repairs are aboutto be written.
File system is clean.
Superblock is marked dirty (FIXED)
All observed inconsistencies have been repaired.

# mount /db2
# cd /db2
# ls

PRD        archlog     db2prd      lost+found

成功挂载，也能正常访问文件系统中的数据。另一个文件系统也使用同样的方法修复。

# fsck /dev/lvsapmnt
The current volume is: /dev/lvsapmnt
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
File system is clean.
Superblock is marked dirty; FIX? yes
All observed inconsistencies have been repaired.

# lsvg -l prdvg
prdvg:
LV NAME            TYPE       LPs     PPs    PVs  LV STATE      MOUNT POINT
lvsaptrans         jfs2       40      40     1    open/syncd    /usr/sap/trans
lvsap              jfs2       20      20     1    open/syncd    /usr/sap/PRD
lvsapmnt           jfs2       20      20     1    closed/syncd  /sapmnt/PRD
lvdb2              jfs2       40      40     1    open/syncd    /db2
lvdata1            jfs2       300     300    2    open/syncd    /db2/PRD/sapdata1
lvdata2            jfs2       300     300    2    open/syncd    /db2/PRD/sapdata2
lvdata3            jfs2       300     300    2    open/syncd    /db2/PRD/sapdata3
lvdata4            jfs2       300     300    3    open/syncd    /db2/PRD/sapdata4
lvarlog            jfs2       198     198    1    open/syncd   /db2arch

prdlog01           jfs2log    1       1      1    open/syncd    N/A

所有文件系统挂载完后，应用正常启动。

1.1 案例总结：

a.任何非正常关机都可能导致文件系统损坏，此次文件系统损坏很可能就是因为非正常关机导致的。

b.关机前建议先执行sync命令将内存数据写入磁盘，保证数据完整性

c.fsck命令修复的文件系统是未mount的，所以对已经挂载的文件系统，请不要使用这条命令！

d.在操作前数据必须备份,另外，此机器上运行的是SAP系统，由于SAP是根据硬件配置动态更新License的（即新增硬件后系统会生成一个新的Hardware Key，而License是根据这个Key来申请的）CPU等硬件的改动会导致原License不可用，SAP系统也将不可用。因此在做类似硬件升级前一定要跟客户说明清楚。

2.fsck原理解析

  先把fsck检查文件系统的内容搬下来，如下：

# fsck -p /dev/lvdb2

The current volume is: /dev/lvdb2

Primary superblock is valid.

*** Phase 1 - Initial inode scan

*** Phase 2 - Process remaining directories

*** Phase 3 - Process remaining files

*** Phase 4 - Check and repair inode allocation map

*** Phase 5 - Check and repair block allocation map

Block allocation map is corrupt (FIXED)【块分配图出现错误（已经修复好）】

Superblock marked dirty because repairs are about to be written.【超级块被标记为dirty，因为修复信息即将写入】

File system is clean.【文件系统干净——修复成功】

Superblock is marked dirty (FIXED)【超级块被标记为dirty（已修复）】

All observed inconsistencies have been repaired.【所有被检查出的不一致性已经被修复好】

2.1 fsck command修复文件系统时做了些什么？

仔细看

    fsck检查文件系统时，首先判断出此逻辑卷是什么，然后检查superblock的可用性，再然后扫描并初始化inode，最后检验并修复出现有错误的superblock、inode和block，最后做一个总结报告出哪些已经修复好的问题。

2.2 fsck修复文件系统带出了几个很陌生的术语：superblock、inode、dirty等，他们分别又是什么意思呢？ 文件系统的架构又是怎么样的呢？

2.3还有亮点，亲，你发现了吗？为什么fsck检查文件系统时，会出现*** Phase 1，*** Phase 2。。。*** Phase 5，这个又有啥意思呢？

为了一 一弄懂这些个问题，我们必须先了解文件系统的构架

3 文件系统构架分析

      文件系统创建（格式化）时，就把存储区域分为两大连续的存储区域。一个用来保存文件系统对象的元信息数据，这是由inode组成的表，每个inode默认是256字节或者128字节。另一个用来保存“文件系统对象”的内容数据，划分为512字节的扇区，以及由8个扇区组成的4K字节的块。块是读写时的基本单位。一个文件系统的inode的总数是固定的。这限制了该文件系统所能存储的文件系统对象的总数目。典型的实现下，所有inode占用了文件系统1%左右的存储容量。

      文件系统中每个“文件系统对象”对应一个“inode”数据，并用一个整数值来辨识。这个整数常被称为inode号码（“i-number”或“inode number”）。由于文件系统的inode表的存储位置、总条目数量都是固定的，因此可以用inode号码去索引查找inode表。

      Inode存储了文件系统对象的一些元信息，如所有者、访问权限（读、写、执行）、类型（是文件还是目录）、内容修改时间、inode修改时间、上次访问时间、对应的文件系统存储块的地址，等等。知道了1个文件的inode号码，就可以在inode元数据中查出文件内容数据的存储地址，

AIX系统中通过命令 #istat filename可以看到inode信息

   

再来了解一下文件系统如何存取文件的

a、根据文件名，通过Directory里的对应关系，找到文件对应的Inode number
b、再根据Inode number读取到文件的Inode table
c、再根据Inode table中的Pointer读取到相应的Blocks

这里有一个重要的内容，就是Directory，他不是我们通常说的目录，而是一个列表，记录了一个文件/目录名称对应的Inode number。如下图

通过文件名打开文件，实际上是分成三步实现：

首先，找到这个文件名对应的inode号码；

其次，通过inode号码，获取inode信息；

最后，根据inode信息，找到文件数据所在的block，读出数据

想到这里，不得不提到的是：我们经常在电脑上删除文件，那这个删除动作到底对文件的元数据和inode做了些什么操作？

事实上， 当我们删除文件的时候，只是把Inode标记为可用，文件在block中的内容是没有被清除的，只有在有新的文件需要占用block的时候，才会被覆盖。

嗯，说了好久的文件系统，那么fsck在进行文件系统那个检查时，是对谁进行了扫描和修复？？

我想，聪明的你看了这么多的描述后，应该对文件系统有个初步了解的同时，也应该想到了fsck会对谁进行操作了。是吗？

是的！fsck操作肯定是对针对某个文件，然后通过与什么跟什么进行对比，如果不一致就根据作为标准的文件作为基准 进行文件的修复。呵呵，还是云里雾里。

接下来，我们来拨开云团见天日罗！

事实上，JFS2文件系统或者ext3或者GPFS文件系统都会有一个共同的特点：拥有一个相对应的日志文件（gpfs的文件系统日志叫：recovery log）

那么这个日志又会是怎么一个结构呢？

这个日志记录所有文件系统的metadata，包括superblock（超级块），inodes（i-nodes），间接数据指针（indirect data pointers)和目录（directories）

当文件的meta-data发生变化时，变化动作会被记录到这个日志中。事实上fsck执行了sync（）和fsync（），就是通过这个日志的内容为基准来进行文件的恢复的。