Ubuntu 12.04
Файловая система часто переходит в режим только для чтения. Прежде всего я прочитал этот вопрос файловая система часто переходит в режим только для чтения уже. Но я должен знать, не вызвано ли это чем-то другим, кроме dying hard drive. Это сервер, предоставленный моим клиентом, и я просто запускаю там несколько node.js workers + один node.js server и я использую mongodb.
Время от времени (каждые 20-50 часов) система внезапно делает файловую систему доступной только для чтения, процесс mongodb завершается сбоем (из-за fs только для чтения) и мои рабочие / сервер node (которые запускаются forever) просто убиты.
Вот журнал 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.
Теперь, когда я набираю любую команду, которой нет в оболочке, я получаю следующее:
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. И они сказали мне, что «принудительное включение fsck в fstab должно помочь» ...
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,noexec,nosuid,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,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /media/psf type prl_fs (rw,nosuid,nodev,sync,noatime,share,_netdev)
Так что на самом деле sda drive нет? Только 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 для подтверждения (smartctl -t long /dev/sda), но я был бы склонен заменить его как можно скорее.
редактировать: the smartctl Команда, которую я дал, верна, как написано. Благодарим за указание режима отказа в вашем вопросе; похоже, что либо у вас очень старое оборудование, либо на пути есть какой-то уровень трансляции: либо виртуализация, либо аппаратный RAID-контроллер. Вы можете уточнить?
Могу я повторить свое утверждение, что ваш жесткий диск выходит из строя? Тестирование проходит очень хорошо, но сейчас вашим приоритетом должна быть замена оборудования до того, как ваша система загрузится и ваши данные будут потеряны. Пожалуйста, по крайней мере убедитесь, что ваши резервные копии полностью обновлены прежде чем тратить больше времени на smartctl.
Редактировать 2: определенно стоит попробовать то, что они предложили - проверить файловую систему - но я мало надеюсь, что это решит проблему, потому что ваша FS не переключается в режим ro из-за несоответствий FS, она переключается в режим ro из-за проблем разговаривает с базовым оборудованием.
Если они уверены, что базовое оборудование в порядке, значит, проблема между ядром и оборудованием, то есть уровнем виртуализации. Вероятно, вам следует попросить вашего поставщика VPS подтвердить, что дистрибутив и точная версия ядра, которые вы используете, полностью поддерживаются в их системе VPS.
Я также столкнулся с той же проблемой, когда серверная FS перешла в режим только для чтения. Сделайте проверку inode, возможно, они заполнены:
df -i
Более совершенный способ найти точную ошибку может быть во время периода только для чтения и запустить команду dmesg на наличие ошибок / проблем. Вы также можете попробовать запустить fsck в сухом режиме, чтобы выяснить, в чем проблема. (извините из-за ограничения доступа, я не могу просмотреть ваше вложение. Если это во время периода выдачи, я проверю его позже)