|
如果一个文件系统的超级块(superblock)损坏了，文件系统不能够被访问，大多数超级块的损坏是不能够被修复的，下面的步骤介绍了当文件系统的超级块损坏是由于一个损坏的magic number引起时如何修复。如果在JFS2文件系统里的基本超级块损坏了，使用fsck命令能够自动地拷贝第二个超级块来修复基本超级块。
在下面的例子中，假设/home/myfs是建立在逻辑卷/dev/lv02上的一个日志文件系统。
1. 用下面的命令来卸载你怀疑损坏的文件系统/home/myfs：
umount /home/myfs
为了进一步确认文件系统的损坏，对文件系统运行如下命令：
fsck -p /dev/lv02
如果问题是超级块的损坏，fsck命令将返回下面的信息：
fsck: Not an AIXV5 file system
或者是
Not a recognized filesystem type
2.使用root用户的权限，使用od命令来显示文件系统的超级块：
od -x -N 64 /dev/lv02 +0x1000
0001000 1234 0234 0000 0000 0000 4000 0000 000a
0001010 0001 8000 1000 0000 2f6c 7633 0000 6c76
0001020 3300 0000 000a 0003 0100 0000 2f28 0383
0001030 0000 0001 0000 0200 0000 2000 0000 0000
0001040
在前述的输出里，注意到在0x1000损坏的magic值（1234 0234）。当文件系统被建立时使用默认值，magic number应该是0x43218765,如果任何默认值被更改过，magic number应该是0x65872143。
3.使用od命令来检查第二个超级块上的正确的magic number：
od -x -N 64 /dev/lv02 +0x1f000
001f000 6587 2143 0000 0000 0000 4000 0000 000a
001f010 0001 8000 1000 0000 2f6c 7633 0000 6c76
001f020 3300 0000 000a 0003 0100 0000 2f28 0383
001f030 0000 0001 0000 0200 0000 2000 0000 0000
001f040
注意到在0x1f000的正确magic值。
4.拷贝第二个超级块到基本超级块：
dd count=1 bs=4k skip=31 seek=1 if=/dev/lv02 of=/dev/lv02
dd: 1+0 records in.
dd: 1+0 records out.
5.使用fsck命令来清理由于使用第二个超级块而引起的不一致的文件：
fsck /dev/lv02 2>&1 | tee /tmp/fsck.errs
我进行的实验如下，文件系统为JFS：
[test2:/]#od -x -N 64 /dev/lv07 +0x1000
0001000 4321 8765 0000 0000 0000 0800 0000 0001
0001010 0002 0000 1000 0000 2f74 6573 7431 6c76
0001020 3037 0000 0033 0006 0100 0000 4940 67f3
0001030 0000 0000 0000 0000 0000 0000 0000 0000
0001040
[test2:/]#od -x -N 64 /dev/lv07 +0x1f000
001f000 4321 8765 0000 0000 0000 0800 0000 0000
001f010 0002 0000 1000 0000 2f74 6573 7431 6c76
001f020 3037 0000 ffff ffff 0000 0000 4940 67f3
001f030 0000 0000 0000 0000 0000 0000 0000 0000
001f040
[test2:/]#od -x -N 64 /dev/lv07 +0x1004
0001004 4321 8765 0000 0000 0000 0800 0000 0001
0001014 0002 0000 1000 0000 2f74 6573 7431 6c76
0001024 3037 0000 0033 0006 0100 0000 4940 67f3
0001034 0000 0000 0000 0000 0000 0000 0000 0000
0001044
[test2:/]#dd if=/dev/lv07 of=/dev/lv07 bs=4k count=1 seek=1 skip=18
1+0 records in
1+0 records out --刻意去破坏主超级块
[test2:/]#od -x -N 64 /dev/lv07 +0x1000 --主超级块的内容发生变化
0001000 0a56 6965 7720 6472 6f70 7065 642e 0a0a
0001010 6472 6f70 2070 7562 6c69 6320 7379 6e6f
0001020 6e79 6d20 2053 5441 5453 2458 244b 4342
0001030 4657 4149 540a 2020 2020 2020 2020 2020
0001040
[test2:/]#od -x -N 64 /dev/lv07 +0x1f000
001f000 4321 8765 0000 0000 0000 0800 0000 0000
001f010 0002 0000 1000 0000 2f74 6573 7431 6c76
001f020 3037 0000 ffff ffff 0000 0000 4940 67f3
001f030 0000 0000 0000 0000 0000 0000 0000 0000
001f040
[test2:/]#umount /test1
[test2:/]#mount /test1
[test2:/]#cd /test1
[test2:/test1]#ls
lost+found spcpkg.lis spctab.lis spcusr.lis spdtab.lis spdusr.lis
[test2:/test1]#od -x -N 64 /dev/lv07 +0x1000
0001000 4321 8765 0000 0000 0000 0800 0000 0002
0001010 0002 0000 1000 0000 2f74 6573 7431 6c76
0001020 3037 0000 0033 0006 0100 0000 4940 67f3
0001030 0000 0000 0000 0000 0000 0000 0000 0000
0001040
--可以正常MOUNT，估计在mount的时候做了fsck。 | 