Linux下文件系统superblock故障修复.docx

1、Linux下文件系统superblock故障修复Linux下文件系统superblock故障修复记一次 superblock 损坏导致服务器无法启动的故障修复前几天接到朋友联系，说他的服务器坏了，启动不起来了。这是一个RHEL 4的服务器，而且是那种盗版RHEL 4，也就是说没有售后服务的，联系我问问能不能帮帮忙。我也很久没有弄过Linux系统上的东西了。只好尝试一下，庆幸的是，修好了，并帮朋友维护了一段时间，在此记录一些修复和维护中碰到的问题。修复 superblock 本身并不复杂，我觉得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。一、启动故障系统无法启动，启动时内核pani

2、c：UncompressingLinuxOk,bootingthekernel.audit(1297269214.612:0):initializedide2:I/Oresource0x3F6-0x3F6notfree.ide2:portsalreadyinuse,skippingprobeRedHatnashversion4.1.18startingFiledescriptor3leftopenReadingallphysicalvolumes.Thismaytakeawhile/dev/hda:openfailed:NomediumfoundFoundvolumegroupVolGroup

3、_ID_17253usingmetadatatypelvm2Filedescriptor3leftopen8logicalvolume(s)involumegroupVolGroup_ID_17253nowactiveFiledescriptor3leftopenVFS:Cantfindext3filesystemondevdm-0.mount:error22mountingext3mount:error2mountingnoneswitchroot:mountfailed:22umount/initrd/devfailed:2Kernelpanic-notsyncing:Attemptedt

4、okillinit!_看到这个报错，我Google了一下，很快就发现，这很有可能是硬盘的superblock1 坏了，因此感觉需要修复superblock。询问了一下，瘫痪之前都发生了些什么。朋友提到了一个情况，在瘫痪前，他发现有一个目录存储了太多的文件了(确实非常的多，大约是几百万到上千万个文件，程序设计上有问题)，这是他写的一个php做缓存的脚本生成的后缀为.php的文件，绝大多数都已经是垃圾文件了。他觉得太占磁盘空间了，想清理一下，于是用下面的命令删除这些生成的文件:find.-name*.php-execrm-f;可是执行命令后，等了几分钟，发现系统没有反应。于是就Ctrl-C了，后来

5、发现系统还是很慢，于是就执行reboot了。接下来，系统就启动不起来了。可以推断，其实并不是系统没有反应，而是删除如此大量的文件，需要相当的时间，当Ctrl-C后，磁盘写入行为并没有因此而立即停止，在如此密集磁盘写入时执行reboot，确实比较容易引起磁盘上的故障。再加上这块硬盘虽然是ext3，但是日志使用的是默认的ordered 2，出问题的几率就更大了，所以怀疑是 superblock 的可能性就更大了。二、修复环境当时朋友有些慌张了，因为他认为这是他操作失误导致服务器瘫痪，有些不知道该怎么办了，那天我有事情比较忙，打算晚些时候再回来帮他。随后的操作中可以看到他做了很多危险的操作，我会一一

6、提出来，大家有类似情况的时候，一定要注意。首先是他把硬盘直接拆下来来了，打算拿回公司备份。备份的想法是好的，如果有合适的服务器，拆下来接过去备份也是对的。但是问题就在于，这是一块SCSI接口的硬盘，是一堆Linux分区，使用的还是LVM 3，而他公司没有一个SCSI接口的机器，他可能还需要去市场上买个SCSI卡，而且，他也没有一台Linux的机器，全是Windows，他甚至打算使用explore2fs之类的不成熟的软件来挂载这块硬盘。这问题就大了。买的SCSI卡的稳定性如何？别是杂牌的，卡再造成硬盘的二次数据损失。用Windows备份可能损坏的硬盘的数据是非常危险的，explorer2fs这类

7、Windows挂载ext2/3分区的软件从来就没成熟过，至今为止还有大量的特性不支持，只是试验产品。使用他们挂载分区，很可能会造成数据损失。另外，之前说过，问题很可能是superblock出问题了，这种情况下，不修复 superblock ，谁也别想挂载成功，而Windows上显然没有这类软件。碰到这类问题，比较好的办法是使用另一台具有SCSI接口的Linux，进行修复、挂载、备份。当然，对于朋友而言，这不现实。那就折中，还在原服务器上修复，但是使用 Linux LiveCD 进行修复，将数据备份到外置 USB 硬盘上。这里需要注意的是，即使硬盘有几个分区，只坏了一个，备份到其它貌似还好的分区

8、似乎也不是什么大问题。但是，在修复、备份的时候，一定要尽可能的避免被修复磁盘的写操作，无论是哪个分区。因为在问题确认修复前，你并不能肯定只有那个报错的分区有故障，其它一切正常。那天朋友在机房的时候，他什么都没有带，只能眼睁睁的一次次的重启，看错误日志，试着能不能进系统。这是很不好的，如果怀疑硬盘出了故障，那么这么一次次重启很容易加重问题，因此一定要避免。没有任何修复环境是没有办法工作的。我让朋友回去准备几张光盘，都是可引导的修复盘。朋友对 Linux 有一些经验但不是很熟悉，折中起见，我让朋友准备了 Fedora 14、Ubuntu 10.10、UBCD等光盘备用，并且打算使用 Fedora

9、14 的 Live CD 进行修复。并且第二天带一个大容量的，最好是空的USB硬盘来，备份数据。并且，在家用 Fedora 14 启动一下，看看怎么进入命令行模式，第二天启动的时候，不要进入图形界面。在命令行模式下修复。第二天约好时间后，看了他的gtalk留言，感觉是一身冷汗啊。首先是告诉我，在服务器上 Fedora 启动后直接进桌面了，没有选项，点了点不知道怎么修复，甚至打开了故障硬盘的几个分区，没找到需要备份的文件。于是乎，又启动了Ubuntu选择了修复坏系统，结果发现要安装文件，然后报错说没有硬盘，于是退出了。敢情这哥们直接把我说的话当耳旁风，在故障服务器上直接启动图形界面，更甚的是，他

10、还尝试让 Ubuntu 覆盖安装 RHEL 4。幸好分区的 superblock 是坏的，不然全毁了。这里面有三个错误。首先是不应该启动图形界面，其次是错误的理解了 Ubuntu 中修复系统选项的含义，然后是在菜单上点击服务器分区从而激发了绑定操作，很可能直接造成写入操作。这些都应该是前一天晚上回家琢磨的，他显然偷懒了，直接拿故障环境练手。如果不是这哥们命大，而且系统出的问题没有那么严重，那么这些连续的错误，很可能造成不可挽回的结果。虽然对于 Windows 用户来说，看着纯命令行觉得无从下手，但是，得到了美丽的界面往往意味着你得付出些什么。在以前的某些 LiveCD 中，加载图形界面的时候，

11、由于各种驱动和程序的加载，错误的进行了硬盘的写操作，从而导致有些人抱怨过启动 LiveCD 导致硬盘数据二次损坏，最终使得修复无望。虽然，最近这些版本的 LiveCD 可能没有这类问题，但是为了避免万一，应当尽量减少对硬盘写入操作的可能性。既然所有修复行为都会在命令行模式下进行，那就没必要启动图形界面冒风险。我让他带着 Ubuntu 的盘就是以防万一，万一 Fedora 启动出现奇怪的问题，我们可以用 Ubuntu 启动然后修复系统。而不是进入 Ubuntu的修复系统选项。那个选项是给 Ubuntu 系统准备的，是以光盘上的系统文件及配置覆盖硬盘上的系统文件及配置，从而达到修复系统的目的。这显

12、然和我们要修复的 RHEL 驴唇不对马嘴。修复系统所需要的只是一个 Linux 环境而已。至于最后在菜单上点击硬盘分区，甚至还打开里面的文件看看，这就是纯属找死了。系统已经报错了，即使能够挂载成功，文件系统也很可能是有问题的，必须在访问前先fsck，否则很可能会引发更大的问题。毕竟默认 Fedora 挂载可不是只读，而是可读写，混乱后，谁也无法预测会把硬盘写成啥样。三、确认问题该准备的光盘准备了，不该操作的操作也做了，这让我很无语，虽然怀疑仅仅是逻辑错误导致superblock坏掉，应该不会有大问题，但还是让我对这次修复的可能性感到怀疑。至少这朋友完全不按照我说的办，经常的做些自己觉得没什么的

13、危险操作，哎，前景黯淡啊。既然他已经改点的都点了，该造成的损坏基本上也造成了。那就在 Fedora LiveCD 的图形界面下修复吧，至少他还可以更方便的把命令返回结果通过 firefox 给我发过来。比用 android 手机通讯好多了。首先我需要知道，都有哪些文件系统被他挂载了，另外，系统上有哪些分区。rootlocalhostliveuser#mount|grepLogVol/dev/mapper/VolGroup_ID_17253-LogVol4on/media/0edef924-567f-45fc-9609-51722cad6e9etypeext3(rw,nosuid,nodev,u

14、helper=udisks)/dev/mapper/VolGroup_ID_17253-LogVol7on/media/ee0c40c6-d9d1-4a81-9806-9991621db1ddtypeext3(rw,nosuid,nodev,uhelper=udisks)/dev/mapper/VolGroup_ID_17253-LogVolHomeon/media/f524534e-3d24-4a22-b475-9e4b7dac0d35typeext3(rw,nosuid,nodev,uhelper=udisks)/dev/mapper/VolGroup_ID_17253-LogVol6on

15、/media/12953c57-baba-4358-baeb-cdd17d6513a2typeext3(rw,nosuid,nodev,uhelper=udisks)好嘛，据我所知，服务器上好像有5个绑定目录的分区，LogVol3,4,6,7,Home，LogVol3 好像就是那个坏的分区，想绑也绑不上，除了它，他全绑上了。我需要确定 LVM 总共有哪些分区，lvscan 命令可以告诉我们LVM下面的分区情况。rootlocalhostliveuser#lvscanACTIVE/dev/VolGroup_ID_17253/LogVol310.00GiBinheritACTIVE/dev/Vol

16、Group_ID_17253/LogVol41.06GiBinheritACTIVE/dev/VolGroup_ID_17253/LogVol753.56GiBinheritACTIVE/dev/VolGroup_ID_17253/LogVol65.38GiBinheritACTIVE/dev/VolGroup_ID_17253/LogVol12.00GiBinheritACTIVE/dev/VolGroup_ID_17253/LogVol02.00GiBinheritACTIVE/dev/VolGroup_ID_17253/LogVol264.00MiBinheritACTIVE/dev/V

17、olGroup_ID_17253/LogVolHome29.44GiBinherit嗯，LogVol0,1是交换分区，LogVol2肯定不是我们的目标，那么缺失的是LogVol3，这个分区出问题了。如此，我们手动绑定一下 LogVol3 看一下报错信息。rootlocalhostliveuser#mkdir/media/myrootrootlocalhostliveuser#mount-text3/dev/mapper/VolGroup_ID_17253-LogVol3/media/myrootmount:wrongfstype,badoption,badsuperblockon/dev/ma

18、pper/VolGroup_ID_17253-LogVol3,missingcodepageorhelperprogram,orothererrorInsomecasesusefulinfoisfoundinsyslog-trydmesg|tailorso这里我们可以直接看到报错说 bad superblock 信息。然后我们再看一下内核报错。rootlocalhostliveuser#dmesg|tail-n20343.583694EXT3-fs(dm-3):mountedfilesystemwithordereddatamode343.585926SELinux:initialized(d

19、evdm-3,typeext3),usesxattr346.179128EXT3-fs:barriersnotenabled346.183702kjournaldstarting.Commitinterval5seconds346.189688EXT3-fs(dm-4):usinginternaljournal346.189694EXT3-fs(dm-4):mountedfilesystemwithordereddatamode346.193216SELinux:initialized(devdm-4,typeext3),usesxattr348.911539EXT3-fs:barriersn

20、otenabled348.918113kjournaldstarting.Commitinterval5seconds348.918151EXT3-fs(dm-9):warning:mountingfswitherrors,runninge2fsckisrecommended348.922722EXT3-fs(dm-9):usinginternaljournal348.922728EXT3-fs(dm-9):mountedfilesystemwithordereddatamode348.922738SELinux:initialized(devdm-9,typeext3),usesxattr3

21、50.225535EXT3-fs:barriersnotenabled350.230730kjournaldstarting.Commitinterval5seconds350.236075EXT3-fs(dm-5):usinginternaljournal350.236081EXT3-fs(dm-5):mountedfilesystemwithordereddatamode350.241386SELinux:initialized(devdm-5,typeext3),usesxattr1957.796112EXT3-fs(dm-2):error:cantfindext3filesystemo

22、ndevdm-2.2688.247855EXT3-fs(dm-2):error:cantfindext3filesystemondevdm-2.这里我们看到，内核报错说无法在 dm-2 上找到 ext3 文件系统。这很有可能就是 superblock 损坏造成的问题。另外，我们看到，正如我所担心的那样，不仅仅是 dm-2 (LogVol3) 有故障， dm-9 分区也有故障。很可能其它分区也有问题，都需要在使用前，进行磁盘检查 fsck。冒失的访问，很可能会造成数据损坏或丢失。如此，我们基本上可以确定是 superblock 的损坏，至于是否还有其它故障，以及是否有数据损失，需要在 fsck

23、之后才能知道了。四、镜像备份损坏的硬盘执行 fsck 会对磁盘进行写操作，我们需要在此之前对磁盘进行镜像备份。这样万一 fsck 的修复造成了更大的损失，我们还可以恢复原始状态。我让朋友插上 USB 硬盘，桌面上会自动出现这个硬盘的图标，如果没有菜单上也会有，点击菜单项打开这个 USB 硬盘，会触发 Fedora 自动绑定该硬盘。这么操作省的朋友敲命令了 (心里想，反正之前不该点的也都点了，破罐破摔吧)。通过 mount 命令找到新绑定的磁盘路径：/dev/sdb1on/media/BACKUPtypefuseblk(rw,nosuid,nodev,allow_other,blksize=40

24、96,default_permissions)然后，开始镜像 LogVol3：rootlocalhost#ddif=/dev/VolGroup_ID_17253/LogVol3|gzip/media/BACKUP/server_root_image.gz20971520+0recordsin20971520+0recordsout10737418240bytes(11GB)copied,666.429s,16.1MB/s确认一下文件确实存在：rootlocalhost#ls-l/media/BACKUP/*.gz-rwxrwxrwx.1liveuserliveuser5943229016Feb

25、1017:29/media/BACKUP/server_root_image.gz五、修复先进行第一次修复尝试。rootlocalhostliveuser#fsck.ext3-B1024/dev/mapper/VolGroup_ID_17253-LogVol3e2fsck1.41.12(17-May-2010)fsck.ext3:Superblockinvalid,tryingbackupblocksfsck.ext3:Badmagicnumberinsuper-blockwhiletryingtoopen/dev/mapper/VolGroup_ID_17253-LogVol3Thesupe

26、rblockcouldnotbereadordoesnotdescribeacorrectext2filesystem.Ifthedeviceisvalidanditreallycontainsanext2filesystem(andnotswaporufsorsomethingelse),thenthesuperblockiscorrupt,andyoumighttryrunninge2fsckwithanalternatesuperblock:e2fsck-b8193这里面说无法修复，原因是 superblock 损坏了，所以 fsck 无法定位相关分区数据。建议使用备份的 superbl

27、ok。我们知道，superblock 对于分区而言非常重要，因此 ext2/3 文件系统将 superblock 备份到了磁盘的各个位置，如此多的备份，降低了所有 superblock 备份都损坏的概率。可是问题是，这些备份在哪里呢？superblock 的备份是和 block size 相关的。询问后得知，这个服务器上的分区的参数都是默认设置，只是调整了一下大小和个数。既然如此，那么所有的分区都应该是同样的 block size，那么它们备份 superblock 的相对位置也都一样。鉴于此，我们打算通过 LogVol7 分区给出一个superblock 备份相对位置的列表：rootloca

28、lhostliveuser#dumpe2fs/dev/VolGroup_ID_17253/LogVol7|grep-isuperblockdumpe2fs1.41.12(17-May-2010)Primarysuperblockat0,Groupdescriptorsat1-4Backupsuperblockat32768,Groupdescriptorsat32769-32772Backupsuperblockat98304,Groupdescriptorsat98305-98308Backupsuperblockat163840,Groupdescriptorsat163841-16384

29、4Backupsuperblockat229376,Groupdescriptorsat229377-229380Backupsuperblockat294912,Groupdescriptorsat294913-294916Backupsuperblockat819200,Groupdescriptorsat819201-819204Backupsuperblockat884736,Groupdescriptorsat884737-884740Backupsuperblockat1605632,Groupdescriptorsat1605633-1605636Backupsuperblockat2654208,Groupdescriptorsat2654209-2654212Backupsuperblockat4096000,Groupdescriptorsat4096001-4096004Backupsuperblockat7962624,Groupdescriptorsat7962625-7962628Backupsuperblockat11239424,Groupdescriptorsat112