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

Linux下文件系统superblock故障记一次 superblock 损坏导致服务器无法启动的故障修复前几天接到朋友联系，说他的服务器坏了，启动不起来了。这是一个RHEL 4的服务器，而且是那种盗版RHEL 4，也就是说没有售后服务的，联系我问问能不能帮帮忙。我也很久没有弄过Linux系统上的东西了。只好尝试一下，庆幸的是，修好了，并帮朋友维护了一段时间，在此记录一些修复和维护中碰到的问题。修复 superblock 本身并不复杂，我觉得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。 一、启动故障 系统无法启动，启动时内核panic： Uncompressing?Linux?Ok,?booting?the?kernel.audit(1297269214.612:0):?initializedide2:?I/O?resource?0x3F6-0x3F6?not?free.ide2:?ports?already?in?use,?skipping?probeRed?Hat?nash?version?4.1.18?startingFile?descriptor?3?left?open??Reading?all?physical?volumes.??This?may?take?a?while??/dev/hda:?open?failed:?No?medium?found??Found?volume?group?VolGroup_ID_17253?using?metadata?type?lvm2File?descriptor?3?left?open??8?logical?volume(s)?in?volume?group?VolGroup_ID_17253?now?activeFile?descriptor?3?left?openVFS:?Cant?find?ext3?filesystem?on?dev?dm-0.mount:?error?22?mounting?ext3mount:?error?2?mounting?noneswitchroot:?mount?failed:?22umount?/initrd/dev?failed:?2Kernel?panic?-?not?syncing:?Attempted?to?kill?init!?_ 看到这个报错，我Google了一下，很快就发现，这很有可能是硬盘的superblock?[1] 坏了，因此感觉需要修复superblock。询问了一下，瘫痪之前都发生了些什么。朋友提到了一个情况，在瘫痪前，他发现有一个目录存储了太多的文件了(确实非常的多，大约是几百万到上千万个文件，程序设计上有问题)，这是他写的一个php做缓存的脚本生成的后缀为.php的文件，绝大多数都已经是垃圾文件了。他觉得太占磁盘空间了，想清理一下，于是用下面的命令删除这些生成的文件: find?.?-name?*.php?-exec?rm?-f?{}?\; 可是执行命令后，等了几分钟，发现系统没有反应。于是就Ctrl-C了，后来发现系统还是很慢，于是就执行reboot了。接下来，系统就启动不起来了。可以推断，其实并不是系统没有反应，而是删除如此大量的文件，需要相当的时间，当Ctrl-C后，磁盘写入行为并没有因此而立即停止，在如此密集磁盘写入时执行reboot，确实比较容易引起磁盘上的故障。再加上这块硬盘虽然是ext3，但是日志使用的是默认的ordered [2]，出问题的几率就更大了，所以怀疑是 superblock 的可能性就更大了。 二、修复环境 当时朋友有些慌张了，因为他认为这是他操作失误导致服务器瘫痪，有些不知道该怎么办了，那天我有事情比较忙，打算晚些时候再回来帮他。随后的操作中可以看到他做了很多危险的操作，我会一一提出来，大家有类似情况的时候，一定要注意。首先是他把硬盘直接拆下来来了，打算拿回公司备份。备份的想法是好的，如果有合适的服务器，拆下来接过去备份也是对的。但是问题就在于，这是一块SCSI接口的硬盘，是一堆Linux分区，使用的还是LVM [3]，而他公司没有一个SCSI接口的机器，他可能还需要去市场上买个SCSI卡，而且，他也没有一台Linux的机器，全是Windows，他甚至打算使用explore2fs之类的不成熟的软件来挂载这块硬盘。这问题就大了。买的SCSI卡的稳定性如何？别是杂牌的，卡再造成硬盘的二次数据损失。用Windows备份可能损坏的硬盘的数据是非常危险的，explorer2fs这类Windows挂载ext2/3分区的软件从来就没成熟过，至今为止还有大量的特性不支持，只是试验产品。使用他们挂载分区，很可能会造成数据损