文件系统频繁进入只读模式.@H_301_3@首先,我已经阅读了这个问题file system is going into read only mode frequently.@H_301_3@但我必须知道它是否不是因为死于硬盘而引起的.这是我的客户端提供的服务器,我只是在那里运行一些node.js worker一个node.js服务器,我正在使用mongodb.
不时(每20-50h)系统突然使文件系统只读,mongodb进程失败(由于只读的fs),我的节点工作者/服务器(永远启动)刚被杀死.
这是来自dmesg的日志 – 我可以看到一些错误和消息,FS将是只读的,并且还有一些JOURNAL错误,但我想找到这些错误的原因..
http://speedy.sh/Ux2VV/dmesg.log.txt
编辑
smartctl -t long /dev/sda smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.5.0-23-generic] (local build) Copyright (C) 2002-11 by Bruce Allen,http://smartmontools.sourceforge.net SMART support is: Unavailable - device lacks SMART capability. A mandatory SMART command Failed: exiting. To continue,add one or more '-T permissive' options.
我做错了什么?同样适用于sda2.
现在,当我输入shell中不存在的任何命令时,我得到这个:
Sorry,command-not-found has crashed! Please file a bug report at: https://bugs.launchpad.net/command-not-found/+filebug Please include the following information with the report:
EDIT2
我得知这个服务器实际上是VPS,他们告诉我硬盘驱动器没问题,他们在RAID 10上.他们告诉我“在fstab中强制fsck应该有帮助”……
EDIT3
这是mount命令的输出:
/dev/sda2 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,size=10%,mode=0755) none on /run/lock type tmpfs (rw,nodev,size=5242880) none on /run/shm type tmpfs (rw,nodev) none on /media/psf type prl_fs (rw,sync,noatime,share,_netdev)
那么实际上没有sda驱动器?只有sda2?
edit4
fsck -N命令的输出:
root@ubuntu:~# fsck -N sda fsck from util-linux 2.20.1 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 sda /dev/sda2
解决方法
[26729.124569] Write(10): 2a 00 03 96 5a b0 00 00 08 00 [26729.124576] end_request: I/O error,dev sda,sector 60185264 [26729.125298] Buffer I/O error on device sda2,logical block 4593494 [26729.125986] lost page write due to I/O error on sda2
对我来说,这是非常有力的证据表明你的/ dev / sda正在走出困境.您可以对其进行智能测试以进行确认(smartctl -t long / dev / sda),但我倾向于尽快更换它.
编辑:我给出的smartctl命令是正确的.感谢您在问题中显示失败模式;这看起来要么你有非常旧的硬件,要么就是某种转换层:虚拟化或硬件RAID控制器.你能澄清一下吗?
我可以重复一下你的硬盘驱逐出路的断言吗?测试非常好,但在系统打包和数据丢失之前更换硬件应该是您的首要任务.请至少确保备份完全是最新的,然后再浪费在smartctl上.
编辑2:它当然值得尝试他们建议的东西 – fscking文件系统 – 但我没有希望这将解决问题,因为你的FS因为FS不一致而没有掉到ro模式,它正在下降到ro模式,因为与底层硬件交谈的问题.
如果他们确信底层硬件很好,那么它就是内核和硬件之间的问题,即虚拟化层.您可能应该让您的VPS提供商确认您的VPS系统完全支持您正在运行的发行版和确切的内核版本.