记录一次文件系统损坏的修复

文件系统的修复

1.问题：

9.61 manager，启动时报错：

mount： wrong fs type, bad option, bad superblock on /dev/sda2

2. 文件系统坏掉，使用新的HOST安装盘引导，进入liveCD系统，对sda2执行修复：

用fsck.ext4  -y /dev/sda2修复是报如下信息

Could this be a zero-length partition

而且修复明显没有进行；

3. 各种 Google 之后发现造成这个问题的原因是文件系统的 Superblock 损坏了。解决办法是找到文件系统上的备份 Superblock 位置，具体做法有两种：用 dumpe2fs 或者 mke2fs -n。先试了下 dumpe2fs：

root@livecd# dumpe2fs /dev/sda3 | grep -i superblockdumpe2fs 1.39 (29-May-2006)Attempt to read block from filesystem resulted in short read whiletrying to open /dev/sda3. Could this be a zero-length partition.

还是报同样的错误，接着试了下 mke2fs -n，还好这下可以工作：

root@livecd# mke2fs -n /dev/sda2mke2fs 1.39 (29-May-2006)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)17924096 inodes, 35822934 blocks1791146 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=42949672961094 block groups32768 blocks per group, 32768 fragments per group16384 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872

其中标蓝色的部分就是文件系统上的 Superblock 备份，从中挑选一个作为 e2fsck 的参数

e2fsck /dev/sda2 -b 32768

，再进行一次 fsck 操作，结果顺利修复了文件系统。e2fsck 的 -b 选项是指定一个 Superblock 的位置，使用上面的命令中输出的任意一个都可以。可以看到 Superblock 的备份很多，一个不行可以用另一个，实践中所有 Superblock 都损坏的概率很小，因此还是比较安全的。

文件系统对于 Superblock 这类关键数据都会保留多个备份，出现故障的时候修复还是很方便的。我现在的疑问是所有这些 Superblock 备份都会保持和主 Superblock 同步吗？换句话说，备份是的时机是怎样的，如何才能知道哪份备份相对比较新点？先存疑，以后找到答案了再来更新。