1394人阅读
被引用（37）
原文地址：/dancefire/archive//fix-bad-superblock-in-linux.html前几天接到朋友联系，说他的服务器坏了，启动不起来了。这是一个RHEL 4的服务器，而且是那种盗版RHEL 4，也就是说没有售后服务的，联系我问问能不能帮帮忙。我也很久没有弄过Linux系统上的东西了。只好尝试一下，庆幸的是，修好了，并帮朋友维护了一段时间，在此记录一些修复和维护中碰到的问题。修复 superblock 本身并不复杂，我觉得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。一、启动故障系统无法启动，启动时内核panic：Uncompressing&Linux&Ok,&booting&the&kernel.audit(.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:&Can't&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&&坏了，因此感觉需要修复superblock。询问了一下，瘫痪之前都发生了些什么。朋友提到了一个情况，在瘫痪前，他发现有一个目录存储了太多的文件了(确实非常的多，大约是几百万到上千万个文件，程序设计上有问题)，这是他写的一个php做缓存的脚本生成的后缀为.php的文件，绝大多数都已经是垃圾文件了。他觉得太占磁盘空间了，想清理一下，于是用下面的命令删除这些生成的文件:find&.&-name&&*.php&&-exec&rm&-f&{}&\;可是执行命令后，等了几分钟，发现系统没有反应。于是就Ctrl-C了，后来发现系统还是很慢，于是就执行reboot了。接下来，系统就启动不起来了。可以推断，其实并不是系统没有反应，而是删除如此大量的文件，需要相当的时间，当Ctrl-C后，磁盘写入行为并没有因此而立即停止，在如此密集磁盘写入时执行reboot，确实比较容易引起磁盘上的故障。再加上这块硬盘虽然是ext3，但是日志使用的是默认的ordered&，出问题的几率就更大了，所以怀疑是 superblock 的可能性就更大了。二、修复环境当时朋友有些慌张了，因为他认为这是他操作失误导致服务器瘫痪，有些不知道该怎么办了，那天我有事情比较忙，打算晚些时候再回来帮他。随后的操作中可以看到他做了很多危险的操作，我会一一提出来，大家有类似情况的时候，一定要注意。首先是他把硬盘直接拆下来来了，打算拿回公司备份。备份的想法是好的，如果有合适的服务器，拆下来接过去备份也是对的。但是问题就在于，这是一块SCSI接口的硬盘，是一堆Linux分区，使用的还是LVM&，而他公司没有一个SCSI接口的机器，他可能还需要去市场上买个SCSI卡，而且，他也没有一台Linux的机器，全是Windows，他甚至打算使用explore2fs之类的不成熟的软件来挂载这块硬盘。这问题就大了。买的SCSI卡的稳定性如何？别是杂牌的，卡再造成硬盘的二次数据损失。用Windows备份可能损坏的硬盘的数据是非常危险的，explorer2fs这类Windows挂载ext2/3分区的软件从来就没成熟过，至今为止还有大量的特性不支持，只是试验产品。使用他们挂载分区，很可能会造成数据损失。另外，之前说过，问题很可能是superblock出问题了，这种情况下，不修复 superblock ，谁也别想挂载成功，而Windows上显然没有这类软件。碰到这类问题，比较好的办法是使用另一台具有SCSI接口的Linux，进行修复、挂载、备份。当然，对于朋友而言，这不现实。那就折中，还在原服务器上修复，但是使用 Linux LiveCD 进行修复，将数据备份到外置 USB 硬盘上。这里需要注意的是，即使硬盘有几个分区，只坏了一个，备份到其它貌似还好的分区似乎也不是什么大问题。但是，在修复、备份的时候，一定要尽可能的避免被修复磁盘的写操作，无论是哪个分区。因为在问题确认修复前，你并不能肯定只有那个报错的分区有故障，其它一切正常。那天朋友在机房的时候，他什么都没有带，只能眼睁睁的一次次的重启，看错误日志，试着能不能进系统。这是很不好的，如果怀疑硬盘出了故障，那么这么一次次重启很容易加重问题，因此一定要避免。没有任何修复环境是没有办法工作的。我让朋友回去准备几张光盘，都是可引导的修复盘。朋友对 Linux 有一些经验但不是很熟悉，折中起见，我让朋友准备了 Fedora 14、Ubuntu 10.10、UBCD等光盘备用，并且打算使用 Fedora 14 的 Live CD 进行修复。并且第二天带一个大容量的，最好是空的USB硬盘来，备份数据。并且，在家用 Fedora 14 启动一下，看看怎么进入命令行模式，第二天启动的时候，不要进入图形界面。在命令行模式下修复。第二天约好时间后，看了他的gtalk留言，感觉是一身冷汗啊。首先是告诉我，在服务器上 Fedora 启动后直接进桌面了，没有选项，点了点不知道怎么修复，甚至打开了故障硬盘的几个分区，没找到需要备份的文件。于是乎，又启动了Ubuntu选择了修复坏系统，结果发现要安装文件，然后报错说没有硬盘，于是退出了。敢情这哥们直接把我说的话当耳旁风，在故障服务器上直接启动图形界面，更甚的是，他还尝试让 Ubuntu 覆盖安装 RHEL 4。幸好分区的 superblock 是坏的，不然全毁了。这里面有三个错误。首先是不应该启动图形界面，其次是错误的理解了 Ubuntu 中修复系统选项的含义，然后是在菜单上点击服务器分区从而激发了绑定操作，很可能直接造成写入操作。这些都应该是前一天晚上回家琢磨的，他显然偷懒了，直接拿故障环境练手。如果不是这哥们命大，而且系统出的问题没有那么严重，那么这些连续的错误，很可能造成不可挽回的结果。虽然对于 Windows 用户来说，看着纯命令行觉得无从下手，但是，得到了美丽的界面往往意味着你得付出些什么。在以前的某些 LiveCD 中，加载图形界面的时候，由于各种驱动和程序的加载，错误的进行了硬盘的写操作，从而导致有些人抱怨过启动 LiveCD 导致硬盘数据二次损坏，最终使得修复无望。虽然，最近这些版本的 LiveCD 可能没有这类问题，但是为了避免万一，应当尽量减少对硬盘写入操作的可能性。既然所有修复行为都会在命令行模式下进行，那就没必要启动图形界面冒风险。我让他带着 Ubuntu 的盘就是以防万一，万一 Fedora 启动出现奇怪的问题，我们可以用 Ubuntu 启动然后修复系统。而不是进入 Ubuntu的修复系统选项。那个选项是给 Ubuntu 系统准备的，是以光盘上的系统文件及配置覆盖硬盘上的系统文件及配置，从而达到修复系统的目的。这显然和我们要修复的 RHEL 驴唇不对马嘴。修复系统所需要的只是一个 Linux 环境而已。至于最后在菜单上点击硬盘分区，甚至还打开里面的文件看看，这就是纯属找死了。系统已经报错了，即使能够挂载成功，文件系统也很可能是有问题的，必须在访问前先fsck，否则很可能会引发更大的问题。毕竟默认 Fedora 挂载可不是只读，而是可读写，混乱后，谁也无法预测会把硬盘写成啥样。三、确认问题该准备的光盘准备了，不该操作的操作也做了，这让我很无语，虽然怀疑仅仅是逻辑错误导致superblock坏掉，应该不会有大问题，但还是让我对这次修复的可能性感到怀疑。至少这朋友完全不按照我说的办，经常的做些自己觉得没什么的危险操作，哎，前景黯淡啊。既然他已经改点的都点了，该造成的损坏基本上也造成了。那就在 Fedora LiveCD 的图形界面下修复吧，至少他还可以更方便的把命令返回结果通过 firefox 给我发过来。比用 android 手机通讯好多了。首先我需要知道，都有哪些文件系统被他挂载了，另外，系统上有哪些分区。[root@localhost&liveuser]#&mount&|grep&LogVol/dev/mapper/VolGroup_ID_17253-LogVol4&on&/media/0edef924-567f-45fc-9609-51722cad6e9e&type&ext3&(rw,nosuid,nodev,uhelper=udisks)/dev/mapper/VolGroup_ID_17253-LogVol7&on&/media/ee0c40c6-d9d1-4a81-9806-dd&type&ext3&(rw,nosuid,nodev,uhelper=udisks)/dev/mapper/VolGroup_ID_17253-LogVolHome&on&/media/fd24-4a22-b475-9e4b7dac0d35&type&ext3&(rw,nosuid,nodev,uhelper=udisks)/dev/mapper/VolGroup_ID_17253-LogVol6&on&/media/12953c57-baba-4358-baeb-cdd17d6513a2&type&ext3&(rw,nosuid,nodev,uhelper=udisks)好嘛，据我所知，服务器上好像有5个绑定目录的分区，LogVol{3,4,6,7,Home}，LogVol3 好像就是那个坏的分区，想绑也绑不上，除了它，他全绑上了。我需要确定 LVM 总共有哪些分区，lvscan 命令可以告诉我们LVM下面的分区情况。[root@localhost&liveuser]#&lvscanACTIVE&'/dev/VolGroup_ID_17253/LogVol3'&[10.00&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol4'&[1.06&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol7'&[53.56&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol6'&[5.38&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol1'&[2.00&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol0'&[2.00&GiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVol2'&[64.00&MiB]&inheritACTIVE&'/dev/VolGroup_ID_17253/LogVolHome'&[29.44&GiB]&inherit嗯，LogVol{0,1}是交换分区，LogVol2肯定不是我们的目标，那么缺失的是LogVol3，这个分区出问题了。如此，我们手动绑定一下 LogVol3 看一下报错信息。[root@localhost&liveuser]#&mkdir&/media/myroot[root@localhost&liveuser]#&mount&-t&ext3&/dev/mapper/VolGroup_ID_17253-LogVol3&/media/myrootmount:&wrong&fs&type,&bad&option,&bad&superblock&on&/dev/mapper/VolGroup_ID_17253-LogVol3,missing&codepage&or&helper&program,&or&other&errorIn&some&cases&useful&info&is&found&in&syslog&-&trydmesg&|&tail&or&so这里我们可以直接看到报错说 'bad superblock' 信息。然后我们再看一下内核报错。[root@localhost&liveuser]#&dmesg&|&tail&-n&20[&343.583694]&EXT3-fs&(dm-3):&mounted&filesystem&with&ordered&data&mode[&343.585926]&SELinux:&initialized&(dev&dm-3,&type&ext3),&uses&xattr[&346.179128]&EXT3-fs:&barriers&not&enabled[&346.183702]&kjournald&starting.&Commit&interval&5&seconds[&346.189688]&EXT3-fs&(dm-4):&using&internal&journal[&346.189694]&EXT3-fs&(dm-4):&mounted&filesystem&with&ordered&data&mode[&346.193216]&SELinux:&initialized&(dev&dm-4,&type&ext3),&uses&xattr[&348.911539]&EXT3-fs:&barriers&not&enabled[&348.918113]&kjournald&starting.&Commit&interval&5&seconds[&348.918151]&EXT3-fs&(dm-9):&warning:&mounting&fs&with&errors,&running&e2fsck&is&recommended[&348.922722]&EXT3-fs&(dm-9):&using&internal&journal[&348.922728]&EXT3-fs&(dm-9):&mounted&filesystem&with&ordered&data&mode[&348.922738]&SELinux:&initialized&(dev&dm-9,&type&ext3),&uses&xattr[&350.225535]&EXT3-fs:&barriers&not&enabled[&350.230730]&kjournald&starting.&Commit&interval&5&seconds[&350.236075]&EXT3-fs&(dm-5):&using&internal&journal[&350.236081]&EXT3-fs&(dm-5):&mounted&filesystem&with&ordered&data&mode[&350.241386]&SELinux:&initialized&(dev&dm-5,&type&ext3),&uses&xattr[&]&EXT3-fs&(dm-2):&error:&can't&find&ext3&filesystem&on&dev&dm-2.[&]&EXT3-fs&(dm-2):&error:&can't&find&ext3&filesystem&on&dev&dm-2.这里我们看到，内核报错说无法在 dm-2 上找到 ext3 文件系统。这很有可能就是 superblock 损坏造成的问题。另外，我们看到，正如我所担心的那样，不仅仅是 dm-2 (LogVol3) 有故障， dm-9 分区也有故障。很可能其它分区也有问题，都需要在使用前，进行磁盘检查 fsck。冒失的访问，很可能会造成数据损坏或丢失。如此，我们基本上可以确定是 superblock 的损坏，至于是否还有其它故障，以及是否有数据损失，需要在 fsck 之后才能知道了。四、镜像备份损坏的硬盘执行 fsck 会对磁盘进行写操作，我们需要在此之前对磁盘进行镜像备份。这样万一 fsck 的修复造成了更大的损失，我们还可以恢复原始状态。我让朋友插上 USB 硬盘，桌面上会自动出现这个硬盘的图标，如果没有菜单上也会有，点击菜单项打开这个 USB 硬盘，会触发 Fedora 自动绑定该硬盘。这么操作省的朋友敲命令了 (心里想，反正之前不该点的也都点了，破罐破摔吧～～)。通过 mount 命令找到新绑定的磁盘路径：/dev/sdb1&on&/media/BACKUP&type&fuseblk&(rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)然后，开始镜像 LogVol3：[root@localhost&~]#&dd&if=/dev/VolGroup_ID_17253/LogVol3&|&gzip&&&/media/BACKUP/server_root_image.gz+0&records&in+0&records&out&bytes&(11&GB)&copied,&666.429&s,&16.1&MB/s确认一下文件确实存在：[root@localhost&~]#&ls&-l&/media/BACKUP/*.gz-rwxrwxrwx.&1&liveuser&liveuser&&Feb&10&17:29&/media/BACKUP/server_root_image.gz五、修复先进行第一次修复尝试。[root@localhost&liveuser]#&fsck.ext3&-B&1024&/dev/mapper/VolGroup_ID_17253-LogVol3e2fsck&1.41.12&(17-May-2010)fsck.ext3:&Superblock&invalid,&trying&backup&blocksfsck.ext3:&Bad&magic&number&in&super-block&while&trying&to&open&/dev/mapper/VolGroup_ID_17253-LogVol3The&superblock&could&not&be&read&or&does&not&describe&a&correct&ext2filesystem.&If&the&device&is&valid&and&it&really&contains&an&ext2filesystem&(and&not&swap&or&ufs&or&something&else),&then&the&superblockis&corrupt,&and&you&might&try&running&e2fsck&with&an&alternate&superblock:e2fsck&-b&8193&&device&这里面说无法修复，原因是 superblock 损坏了，所以 fsck 无法定位相关分区数据。建议使用备份的 superblok。我们知道，superblock 对于分区而言非常重要，因此 ext2/3 文件系统将 superblock 备份到了磁盘的各个位置，如此多的备份，降低了所有 superblock 备份都损坏的概率。可是问题是，这些备份在哪里呢？superblock 的备份是和 block size 相关的。询问后得知，这个服务器上的分区的参数都是默认设置，只是调整了一下大小和个数。既然如此，那么所有的分区都应该是同样的 block size，那么它们备份 superblock 的相对位置也都一样。鉴于此，我们打算通过 LogVol7 分区给出一个superblock 备份相对位置的列表：[root@localhost&liveuser]#&dumpe2fs&/dev/VolGroup_ID_17253/LogVol7&|&grep&-i&superblockdumpe2fs&1.41.12&(17-May-2010)Primary&superblock&at&0,&Group&descriptors&at&1-4Backup&superblock&at&32768,&Group&descriptors&at&32769-32772Backup&superblock&at&98304,&Group&descriptors&at&98305-98308Backup&superblock&at&163840,&Group&descriptors&at&163841-163844Backup&superblock&at&229376,&Group&descriptors&at&229377-229380Backup&superblock&at&294912,&Group&descriptors&at&294913-294916Backup&superblock&at&819200,&Group&descriptors&at&819201-819204Backup&superblock&at&884736,&Group&descriptors&at&884737-884740Backup&superblock&at&1605632,&Group&descriptors&at&1605633-1605636Backup&superblock&at&2654208,&Group&descriptors&at&2654209-2654212Backup&superblock&at&4096000,&Group&descriptors&at&4096001-4096004Backup&superblock&at&7962624,&Group&descriptors&at&7962625-7962628Backup&superblock&at&,&Group&descriptors&at&-尝试使用 32768 的备份：[root@localhost&liveuser]#&fsck.ext3&-B&1024&-b&32768&/dev/mapper/VolGroup_ID_17253-LogVol3e2fsck&1.41.12&(17-May-2010)fsck.ext3:&Bad&magic&number&in&super-block&while&trying&to&open&/dev/mapper/VolGroup_ID_17253-LogVol3The&superblock&could&not&be&read&or&does&not&describe&a&correct&ext2filesystem.&If&the&device&is&valid&and&it&really&contains&an&ext2filesystem&(and&not&swap&or&ufs&or&something&else),&then&the&superblockis&corrupt,&and&you&might&try&running&e2fsck&with&an&alternate&superblock:e2fsck&-b&8193&&device&这个备份还是不行，再换一个：[root@localhost&liveuser]#&fsck.ext3&-b&98304&/dev/VolGroup_ID_17253/LogVol3e2fsck&1.41.12&(17-May-2010)Superblock&needs_recovery&flag&is&clear,&but&journal&has&data.Recovery&flag&not&set&in&backup&superblock,&so&running&journal&anyway./dev/VolGroup_ID_17253/LogVol3:&recovering&journalAdding&dirhash&hint&to&filesystem.Pass&1:&Checking&inodes,&blocks,&and&sizesInode&81,&i_blocks&is&8,&should&be&0.&Fix&y&?不错，98304 这个备份是好的。已经修复了一些内容了，只要继续就很有可能修复系统。不过，当我让朋友点击 y 确认的时候，悲剧又发生了。他在复制粘贴返回信息的时候，习惯了 Windows 的 Ctrl-C 和 Ctrl-V，呃，我们要知道，Ctrl-C 在 命令行下有另外的含义，就是终止程序运行。结果，他按 Ctrl-C 了……[1]+&Stopped&fsck.ext3&-b&98304&/dev/VolGroup_ID_17253/LogVol3磁盘修复一半的时候强行终止退出？我现在非常不确定系统当前的状态和磁盘的状态，我只好让朋友重新启动，重来。重启前跟他说，千万不要再做任何异常的操作了，否则可能系统会无法恢复的。很不幸，我的话又变成了耳旁风。重启后，他兴高采烈的告诉我说，可以看见 LogVol3 啦，不过有些文件夹还是打不开啊。我晕倒～～我非常怀疑他是不是关心硬盘的数据。这个硬盘仅仅是恢复了 superblock，但是必然还有很多其它的问题，冒然以可写形式绑定，磁盘很可能会丢数据的。我给了他严重警告，再这么做我就不帮忙了，我替你担心半天，你反而不听我劝，混不在乎。重新开始修复硬盘：[root@localhost&liveuser]#&fsck.ext3&-y&-b&98304&/dev/VolGroup_ID_17253/LogVol3Free&blocks&count&wrong&for&group&#78&(32254,&counted=5049).Fix?&yesFree&blocks&count&wrong&for&group&#79&(32254,&counted=4724).Fix?&yesFree&blocks&count&wrong&(2566343,&counted=1869026).Fix?&yesFree&inodes&count&wrong&for&group&#0&(16373,&counted=16288).Fix?&yes/dev/VolGroup_ID_17253/LogVol3:&*****&FILE&SYSTEM&WAS&MODIFIED&*****/dev/VolGroup_ID_17253/LogVol3:&229199/1310720&files&(1.6%&non-contiguous),&752414/2621440&blocks经过了一段时间的等待，LogVol3 修复终于完成了。由于得知当时LogVolHome进行了大量的读写，因此，虽然可以挂载，但是非常怀疑其中也有故障，因此也许进行磁盘检查和修复：[root@localhost&/]#&fsck.ext3&/dev/VolGroup_ID_17253/LogVolHomee2fsck&1.41.12&(17-May-2010)/dev/VolGroup_ID_17253/LogVolHome&contains&a&file&system&with&errors,&check&forced.Pass&1:&Checking&inodes,&blocks,&and&sizesPass&2:&Checking&directory&structurePass&3:&Checking&directory&connectivityPass&4:&Checking&reference&countsPass&5:&Checking&group&summary&information/dev/VolGroup_ID_17253/LogVolHome:&2301889/3859072&files&(9.9%&non-contiguous),&2554717/7716864&blocks果然，确实有错误，并且修复了。然后，尝试挂载 LogVol3，看这次是否没有问题了：[root@localhost&/]#&mkdir&/media/myroot[root@localhost&/]#&mount&-t&ext3&/dev/VolGroup_ID_17253/LogVol3&/media/myroot一切正常，没有任何报错。磁盘修复基本可以宣告完成，接下来就是备份和重新启动了。六、备份重要数据重新启动系统，如果一切正常，系统会正常加载所有的服务器，并且开始提供服务，那时数据就会发生改变了，在还不知道服务器是否正常的情况下贸然启动服务器，而没有备份，这是危险的。因此，我们先备份重要数据。[root@localhost&/]#&cd&/media/myroot[root@localhost&myroot]#&tar&-czvf&/media/BACKUP/www.tgz&www[root@localhost&myroot]#&tar&-czvf&/media/BACKUP/server_lampp.tgz&opt/lampp[root@localhost&myroot]#&tar&-czvf&/media/BACKUP/server_mysql.tgz&opt/lampp/var/mysql最后确认一下数据是否已经备份好了。[root@localhost&myroot]#&ls&l&/media/BACKUPtotal&6287380-rwxrwxrwx.&1&liveuser&liveuser&&Feb&10&19:35&server_lampp.tgz-rwxrwxrwx.&1&liveuser&liveuser&&Feb&10&19:30&server_mysql.tgz-rwxrwxrwx.&1&liveuser&liveuser&&Feb&10&17:29&server_root_image.gz-rwxrwxrwx.&1&liveuser&liveuser&&Feb&10&19:34&www.tgz七、重新启动分区修好了，fsck检查各个分区也都没问题了，该备份的都备份了。可以尝试重新启动系统了，祈祷吧……很不幸，没起来。:(启动的过程，系统报错：Remounting&root&filesystem&in&read-write&mode:Setting&up&Logical&Volume&Management:Checking&filesystems/boot:&clean,&38/26208&files,&15754/104420&blocks/dev/VolGroup_ID_17253/LogVol4:&clean,&22/139392&files,&12950/278528&blocks/dev/VolGroup_ID_17253/LogVol7:&clean,&132904/7028736&files,&882601/&blocks/dev/VolGroup_ID_17253/LogVol6:&clean,&22314/704512&files,&168941/1409024&blocks/dev/VolGroup_ID_17253/LogVolHome&contains&a&file&system&with&errors,&check&forced.&/dev/VolGroup_ID_17253/LogVolHome:&Inode&1340876&is&too&big.&/dev/VolGroup_ID_17253/LogVolHome:&UNEXPECTED&INCONSISTENCY;&RUN&fsck&MANUALLY.&&&&&&&&(i.e.,&without&-a&or&-p&options)&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&[FAILED]***&An&error&occurred&during&the&file&system&check.***&Dropping&you&to&a&shell;&the&system&will&reboot***&when&you&leave&the&shell.***&Warning&--&SELinux&is&active***&Disabling&security&enforcement&for&system&recovery.***&Run&'setenforce&1'&to&reenable.Give&root&password&for&maintenance(or&type&Control-D&to&continue):&_经过Google，发现这是 e2fsprogs，也就是 fsck.ext3 所在包，早期版本的一个bug。如果inode节点很大，会触发这个bug。1.40以后就没有这个问题了，这也看出来我一直坚持要升级的原因之一。越早的版本的软件包含的bug就越多，每年新的版本都会修复大量的bug。而那些坚持版本越老越稳定的人，实际上是非常错误的。太新和太老都是不合理的，要取一个合适的折中。像 RHEL 4，甚至5，就太老了。其内很多版本包含了大量的bug，可是由于没有升级到新的版本，RedHat不得不花大力气去将修复bug的补丁打到老的软件上，而有相当数量的补丁是完全基于新版本API的，那些补丁就没有办法打在老软件上。RHEL/CentOS所谓的长期稳定，也就是因为RedHat有大量的人力在做这种将新软件的补丁打到老软件上的事情。可是，有些时候，我们直接用新的版本会更好。我没心思在LiveCD里面升级e2fsprogs，这是个危险的操作。触发这个bug的条件是一个目录下的文件太多，从而导致inode过大。了解了一下，那个目录正好是服务器故障前正在清理的目录。那么我们就先把这个目录清理掉再说。由于这个目录包含有太多的文件，计算了一下清理这个目录会花1-2个小时。已经是凌晨了，写了个脚本，开始执行，清理完文件后，会自动重启。基本上该做的都做了，应该没有什么问题了。脚本执行后，就让朋友回家好了。很幸运，朋友到家后，给我发来消息，服务器正常启动了，Web应用也都开始正常提供服务了。一切似乎都恢复正常了。很庆幸，没有机会用上备份(那就意味着要重装系统之类的大操作了)。八、后记这次系统故障导致我朋友很紧张的原因之一就是系统没有备份。最近一次备份也是几个月前，因此如果硬盘无法恢复，那么直接造成的结果就是这几个月的工作全部丢失。其实使用Linux备份还是比较容易的。最简单的办法是用crontab，定义的压缩一份重要数据，传到别的服务器上去，或者复制到别的物理硬盘上。可惜由于他们公司对 Linux 熟悉的人不多，因此没有人去做而已。这也反映了一个问题。我们经常看到类似于，“什么服务器最安全快速？”、“什么编程语言效率最高？”的问题。这类问题实际上问题本身就有问题。没有最安全的服务器，没有最好的编程语言，只有最合适你的。很多人都说 Linux 如何如何安全，Windows 如何如何脆弱。真不知道这些人从哪得到的数据？还是大脑进水了？如果你说的是精心配置下的服务器，那么很难说谁更安全，Windows 的内核非常健壮，相比 Linux 而言，更稳定和安全。你只要查一下 Linux 内核在过去几年内所出现的安全漏洞的数量，对比一下 Windows 内核的漏洞的数量，你就会发现这个问题。而 IIS 出现的安全漏洞，和 Apache 比起来，谁也不敢说谁更安全。而就配置而言，我们都可以对每个服务器配置执行账户，限定用户权限。相比而言，Windows 的 ACL 比 Linux 的要更复杂和完善。当然，Linux 也有 Linux 的优势。它们是处于一个安全等级上的。无论哪个系统，都可以配置出安全、高效的服务器。但是，你得精心配置啊。我想大多数人对二者的安全配置并不熟悉，也似乎没有花大量的经历和试验去熟悉。那么对大多数人而言，似乎默认配置就是最好的。就像我这个朋友，问他各个配置为什么这样，为什么那样，他几乎都是一个答案，不知道和默认就是这样，没改。这让我很无语。安全界上，凡是默认配置的，基本都是有隐患的。大多数入侵啊、蠕虫啊，也都是针对默认配置的机器做的。不管你是 Linux 也好，Windows 也罢。只要是默认配置，你就不要提什么谁更安全，那是扯淡。还有一个问题就是升级。这个服务器用的是 RHEL，貌似国内好像比较喜欢用这个。虽然其内的软件很老，但是这个发布确实比较稳定，你要是用正版的，有售后支持，我也觉得没什么。但是问题是，国人似乎用盗版成瘾。觉得既然能买 RHEL的盗版盘(甚至是下载，都不用买)，为什么还花钱？这个服务器就是如此。可是，你用盗版，如何升级？而且，盗版的售后找谁？国外用RHEL的人多，那是冲着售后去的，人家有24小时应急响应，服务器出了问题很快就能解决。国内人用 RHEL，还不用带售后，这是为啥？百思不得其解。哪怕你用CentOS呢，虽然没有售后，但起码可以升级啊。呵呵，也许人性使然。不论如何，服务器修好了。一切似乎又恢复了正常。但是，真的如此么？造成这次故障的，致使那个累积了太多文件的php缓存代码还在按照以往工作着，今天出现的问题，说不定什么时候就又会出现。问题需要进一步的挖掘，才能真正的让服务器，健康的运行。当然，今天那个朋友可以好好睡个觉了，下一次出问题，起码也是半个月后了，还有时间来分析和解决深层次的问题。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1610278次
积分：23867
积分：23867
排名：第258名
原创：832篇
转载：55篇
译文：43篇
评论：80条
姓名：lyg ------------------------------ 地点：上海----------------------------- 职位：ebs dba ----------------------- email：
(1)(1)(1)(4)(1)(1)(2)(2)(4)(6)(9)(10)(1)(13)(1)(2)(3)(11)(3)(11)(11)(12)(24)(25)(22)(41)(23)(7)(20)(10)(14)(16)(44)(21)(10)(2)(18)(17)(19)(18)(11)(50)(23)(12)(38)(42)(33)(22)(40)(49)(41)(28)(37)(20)(20)